Re: [gpsd-dev] The attempt to use VTIME has been removed

[Greg Troxel]

"Eric S. Raymond" <address@hidden> writes:

> Nobody ever reported it on the bugtracker.  What I know is that
>
> (1) It reproduces on the Raspberry Pi - I had a long session with a Pi 
> developer 
> on #gpsd during which we discussed the problem, invented the original 
> adaptive-
> delay patch. and verified that it worked on the Pi.
>
> (2) Similar behavior was reported from a couple of specific models of
> Android phone, one of which was the Samsung Galaxy III.
>
> That it's a bug in select(2) is not confirmed, but I've run across racy 
> selects
> before, notably in a buggy PL2303 driver on the Mac.

If it hasn't been shown other than with gpsd, then I still have to
wonder if the issue could be in gpsd.  That's why I was asking about a
bug report with a repro script.

It might be useful to count behaviors in the read() call that's in
theory guarded by select, just incremenenting one counter for input and
one for each kind of output (> 1 char, = 1 char, retval 0, retval -1 and
EINTR, retval -1 and EAGAIN, retval -1 and other errno) and log those at
exit.   I put in a syslog call for retval -1 and got hundreds of hits.
That's as far as I got when the VMIN stuff was removed.

Also, release-3.11-333-gdb26270 passes on netbsd-5/amd64 and
netbsd-6/i386 and has only a single failure "test/daemon/nd-1005.log" on
OS X 10.9 (will rerun; may well be timing).

pgpG3M2LpHhqv.pgp
Description: PGP signature