gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] regression test puzling non-failure which should probably


From: Eric S. Raymond
Subject: Re: [gpsd-dev] regression test puzling non-failure which should probably fail
Date: Thu, 29 Jan 2015 22:08:37 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Hal Murray <address@hidden>:
> 
> address@hidden said:
> > Processing test/daemon/tcp-test.log gpsd:ERROR: TCP device open error can't
> > connect to host/port pair. gpsd:ERROR: tcp://127.0.0.1:49194: device
> > activation failed. 
> 
> I've seen that too.  For me, it doesn't happen very often.  I don't remember 
> what system it happened on.
> 
> I agree that it's a bug that it doesn't get counted as an error (and turn 
> into FAIL).  Either that or the error message is misleading.

This sort of thing will happen randomly and rarely on any test
system. It's because gpsfake wants to tell its slave gpsd instance to
use a port in the private range, but doesn't know what private ports
other programs are using.  So it grabs one at random; once in a blue
moon there will be a collision.  The relevant code is

def fakeport():
    "Find a port that isn't in use to bind to."
    # Grab a random port from IANA's unassigned/private range. Not perfect,
    # but at least less than in 16000 chance of a pair collision. It would
    # be very hard to get this deterministically correct, since there would
    # always be a window between port allocation and when the daemon picked
    # it up.  We'd need to do some kind of semaphore, etc., and even that
    # wouldn't prevent collisions with other apps using the range.
    return random.randint(49152, 65535)

Up to now I haven't seen these collisions frequently enough to justify coding
a more elaborate allocator with test and retry.  That would reduce the 
frequency but, inevitably, have a TOCTOU bug; collisions would still be 
possible.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]