Re: b32ff1a86 Breaks OSX and FreeBSD

[Bernd Zeimetz]

On 12/22/19 3:17 PM, Greg Troxel wrote:

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

its a pty, but the unix socket you are seing is the control socket
gpsfake uses to tell gpsd to connect to the pty.

>From a truss output:

48692: socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 9 (0x9)
48694: pselect(0x7,0x7fffffffe7a0,0x0,0x0,0x0,0x0) = 1 (0x1)
48694: accept(3,{ AF_UNIX "" },0x7fffffffb700)   = 7 (0x7)
48692: connect(9,{ AF_UNIX
"/tmp/gpsd-test-XXXXXXXXXXXXXX.Y4KXv4B9/gpsfake-48692.sock" },59) = 0 (0x0)
48694: read(7,"-/dev/pts/3\r\n\0",1023)          = 14 (0xe)
48694: sendto(6,"{"class":"DEVICE","path":"/dev/p"...,54,0,NULL,0) = 54
(0x36)
48694: write(7,"OK\n",3)                         = 3 (0x3)
48692: sendto(9,"-/dev/pts/3\r\n\0",14,0,NULL,0) = 14 (0xe)
48692: recvfrom(9,"OK\n",12,0,NULL,0x0)          = 3 (0x3)


That regression test did not fail, but it makes me wonder that gpsfake
is already connecting  to the unix socket to send the pty removal
message while it is still sending logs to the pty (FD 6).
But maybe there is something I do not understand here.


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


I think WRITE_PAD needs to go away. Its a workaround for a bug that
should be fixed instead.


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

The CI seems to be more happy, but it still fails on the passtrough.log
test sometimes - thats the one that is trying pty + udp + tcp.


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

Definitely, but we need to figure out what makes it fail all the time.

I think I found a reason for the timeouts at least: subprocess.Popen
seems to have a close_fds=True on BSD as default, and that takes quite
long. Wondering if it is needed...


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

Being able to reproduce it in an easy way would help. Spent some hours
with my FreeBSD VM and was not able to reproduce it manually. Its pretty
random :(

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