Re: b32ff1a86 Breaks OSX and FreeBSD

[Greg Troxel]

Bernd Zeimetz <address@hidden> writes:

> 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.

Ah.  It never occured to me to use -j for testing (or really, at all),
since my build script is basically for looking for trouble and the
interleaved output (that other things produce) is not helpful.

> 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.

I get that, but is the other option "pty" or "unix domain socket"?

> 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.

That sounds good.  I will update and try it, once I finish my
characterization of WRITE_PAD on my current hardware.

> 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.

I am guessing that you mean "after the release".  It seems worthwhile to
fix CI immediately, but that sort of cleanup seems better deferred.

> 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.

I am not quite clear on how this works, as there seems to be an input
stream and an output stream.   For testing things that are supposed to
use terminals, the pty approach seems likely to have more test fidelity,
so from that I would think we'd want to keep it.

> 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.

I agree we should figure this out.  If it is a bug in *BSD ptys, then I
would like to know that precisely so it can be fixed.