Re: [gpsd-dev] NMEA0183 Problems with frames mit checksum errors

[Fred Wright]

On Mon, 5 Sep 2016, Gary E. Miller wrote:
> On Mon, 5 Sep 2016 12:18:21 +0200 (MEST)
> "address@hidden" <address@hidden> wrote:
>
> > i have reported a problem, that gpsd,
> > after getting a number of packets with checksum errors,
> > is trapped in an endless loop testing for other baudrates,
> > and then exit with a segmentation fault after a while.
>
> Until you fix your checksum errors you'll have troubles.  If
> you are getting a lot of checksum errors then a lot of bad data is
> geting through and passing the check sum.

That may well be true, given how lame the NMEA0183 checksum scheme is (and
some of the binary formats aren't much better), but expecting 100%
reliability isn't always realistic.

> So focus on your serial port problem.  You should have zero checksum errors
> in normal operation.

It sounds like there are at least two gpsd bugs that can't be reproduced
with the normal test suite:

1) Being too trigger-happy in switching baud rates after establishing a
valid setting (and thereby garbling valid data as well).

2) Segfaulting in the process.  A segfault isn't a valid response to *any*
input.

If one actually cares about reliability, then one should fix bugs in
"reverse order" as much as possible, in order to exploit earlier bugs as
test cases for later bugs.  It should at least be possible to track down
#2 if the OP could:

A) Build gpsd with the "debug" option (debug=yes).

B) Reproduce the problem with the debug binary and with core dumps
enabled.

C) Provide the core dump, the debug binary, and the git commit ID used for
the build.  This is probably too large for email, so it would need to be
sent via other means.

Understanding #1 doesn't require a test case, but testing a fix would need
it.  There's no "flaky line simulator" in the test framework.

Fred Wright