Re: [gpsd-dev] ✘regress-driver broken

[Fred Wright]

On Thu, 7 Apr 2016, Fred Wright wrote:
> On Thu, 7 Apr 2016, Fred Wright wrote:
> > On Thu, 7 Apr 2016, Eric S. Raymond wrote:
> >
> > > Gary E. Miller <address@hidden>:
> > > > Fails for me.  See below.
> > >
> > > I don't know what's going on here.  Your IRC guess that you may be 
> > > blowing past
> > > a length limit in the test harness may be right.  Won't be Python, as that
> > > has dynamic allocation; might be sed.
> > >
> > > If we can find out whast the real firlds in a 1097 are that would probably
> > > be shorter.
> >
> > I've confirmed that:
> >
> > 1) All discrepancies are due to records (lines) being exactly duplicated.
> >
> > 2) Of the 17 discrepancies, 14 are type 1107, one is type 1019, one is
> > type 1044, and one is type 1046.
> >
> > 3) The duplications are present in the raw output from gpsfake, so the
> > problem isn't sed's fault.
>
> And a bit more investigation shows:
>
> 4) The data is *not* duplicated at the point where client.py receives it
> from the daemon, so it's a test harness bug.

Found it.  The "fragment" case in gpscommon.run wasn't clearing out the
old response, so it got duplicated.  The behavior varies as a function of
how the line boundaries relate to packet-buffer boundaries.

With the fix I also see failures on this test, but I believe that's
because the current "reference" data was captured with the same bug
hitting at different places.  Once I confirm this, I'll send a patch.

All the other tests still pass with the fix.

Fred Wright