[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: b32ff1a86 Breaks OSX and FreeBSD
From: |
Bernd Zeimetz |
Subject: |
Re: b32ff1a86 Breaks OSX and FreeBSD |
Date: |
Sun, 22 Dec 2019 02:48:55 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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
- Re: b32ff1a86 Breaks OSX and FreeBSD, (continued)
- Re: b32ff1a86 Breaks OSX and FreeBSD, Greg Troxel, 2019/12/20
- Re: b32ff1a86 Breaks OSX and FreeBSD, Gary E. Miller, 2019/12/20
- Re: b32ff1a86 Breaks OSX and FreeBSD, Bernd Zeimetz, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Hal Murray, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Bernd Zeimetz, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Greg Troxel, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Bernd Zeimetz, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Greg Troxel, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Bernd Zeimetz, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Greg Troxel, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD,
Bernd Zeimetz <=
- Latest SConstruct (pull a few min ago), Hal Murray, 2019/12/21
- Re: Latest SConstruct (pull a few min ago), Gary E. Miller, 2019/12/22
- Re: b32ff1a86 Breaks OSX and FreeBSD, Greg Troxel, 2019/12/22
- Re: b32ff1a86 Breaks OSX and FreeBSD, Bernd Zeimetz, 2019/12/22
- Re: b32ff1a86 Breaks OSX and FreeBSD, Gary E. Miller, 2019/12/21
- Re: b32ff1a86 Breaks OSX and FreeBSD, Hal Murray, 2019/12/22
- Re: b32ff1a86 Breaks OSX and FreeBSD, Bernd Zeimetz, 2019/12/22
- Re: b32ff1a86 Breaks OSX and FreeBSD, Hal Murray, 2019/12/22