Re: [gpsd-dev] new regression failures

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> I am seeing a lot of failures.  I think they are unrelated to the endian
> fix, and look like they might involve not reading the last line of the
> test input, but I really have no idea.  These failures do not seem
> entirely repeatable.  I'm doing a run of 10.

OK, we've seen this movie before.  Not only that, but *BSD was where
we saw it. In gps/gpsfake.py:

# The two magic numbers below have to be derived from observation.  If
# they're too high you'll slow the tests down a lot.  If they're too low
# you'll get random spurious regression failures that usually look
# like lines missing from the end of the test output relative to the
# check file.  These numbers might have to be adjusted upward on faster
# machines.  The need for them may be symptomatic of race conditions
# in the pty layer or elsewhere.

# Define a per-line delay on writes so we won't spam the buffers in
# the pty layer or gpsd itself.  Removing this entirely was tried but
# caused failures under NetBSD.  Values smaller than the system timer
# tick don't make any difference here.
WRITE_PAD = 0.001

# We delay briefly after a GPS source is exhausted before removing it.
# This should give its subscribers time to get gpsd's response before
# we call the cleanup code. Note that using fractional seconds in
# CLOSE_DELAY may have no effect; Python time.time() returns a float
# value, but it is not guaranteed by Python that the C implementation
# underneath will return with precision finer than 1 second. (Linux
# and *BSD return full precision.) Dropping this to 0.1 has been
# tried but caused failures.
CLOSE_DELAY = 0.2

Keep doubling these until the flaky failures go away, then let me know
how high you had to boost them.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature