Re: b32ff1a86 Breaks OSX and FreeBSD

[Bernd Zeimetz]

On 12/22/19 1:10 AM, Greg Troxel wrote:
>> Could you tcpdump it and see if gpsfake is sending what it is supposed to?
> 
> I was just looking at things with fstat (native NetBSD program that is
> sort of like lsof) and it seems the connection is a unix-domain stream
> socket, not a TCP/localhost.
> 
> Obviously with high enough WRITE_PAD the right data is transferred.  I
> have found that besides the hard-coded default of 0.004, 0.003 works,
> and so far the run with 0.002 is working fine.  Using 0 results in
> failures, though.

That got me on the right track!

In SConstruc is (was!) actually a different way of calling
regress-driver for those cases where scons was called with -j <=1. So
basically exactly what happens on slow platforms with single-core CPUs
or where people don't think about specifying -j x.

In the -j <=1 case the -t option was missing. So regress-driver did not
use tcp - and as these various WRITE_PAD quirks show, the pty does not
work as well on *BSD as it does on Linux.

So I've commited

commit 7d7cdd398f2bb98b3b9d702e1281f1be653b792a (HEAD -> master,
origin/master)
Author: Bernd Zeimetz <address@hidden>
Date:   Sun Dec 22 02:18:17 2019 +0100

    Remove extra case for non-parallel regress driver.

    This was buggy due to:
    - different regress-driver options resulting in pty usage instead of the
    default of using tcp in regress-driver
    - generating a commandline > MAX_ARGS after adding more logs.
    - one implementation covering all cases: better than two where one is
    broken...


Which should hopefully fix the regression tests for those who run them
from scons.


With that change, I think we should not have WRITE_PAD for tcp tests on
*BSD. Should be save to run them without extra sleeps. But as there is
passtrough.log going trough pty + udp + tcp, I can't override it easily
in the CI. So I think I'll add (TCP|UDP|PTY)_WRITE_PAD variables or
something like that.

Running passtrough.log with WRITE_PAD=0 trough pty on my FreeBSD
regularily times out (!) - which might be a pointer to the appropriate
fix for the issue.


So I think the random failures in the CI are gone, but we should still
figure out what wrong with the pty and if the issue is in gpsfake, the
pty itself or the receiving side.
And: if the issues show up again - we can be quite sure the problem is
in gpsd.


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F