[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>
- [gpsd-dev] regression test puzling non-failure which should probably fail, Greg Troxel, 2015/01/29
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Greg Troxel, 2015/01/29
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Hal Murray, 2015/01/29
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail,
Eric S. Raymond <=
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Greg Troxel, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Eric S. Raymond, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Greg Troxel, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Eric S. Raymond, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Hal Murray, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Eric S. Raymond, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Hal Murray, 2015/01/30
- Re: [gpsd-dev] regression test puzling non-failure which should probably fail, Eric S. Raymond, 2015/01/31