gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Hal's sirf1 bug fixed


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Hal's sirf1 bug fixed
Date: Fri, 23 Jan 2015 23:13:42 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Hal Murray <address@hidden>:
> > Unitialized dst field in a struct tm was the problem.
> 
> Interesting.  I would expect the compiler to complain about uninitialized 
> variables.  I guess that logic doesn't catch fields in structs that get 
> passed to subroutines.  Do any of the bug-finder packages look for that case?

ccpcheck and splint bith look for it, but find different and incomplete 
subsets of the error cases.
 
> I'm seeing errors from test/daemon/tcp-test.log
> 
> 2 out of 5 on a Fedora box.  (worked OK on 3 other Fedora boxes)
> 5 out of 5 on a Debian box.
> 3 out of 5 on a Ubuntu box.
> 
> Within a box, the errors are all the same.  2 boxes get the same error.  The 
> 3rd box is different.
> 
> Here is a sample.
> 
> Processing test/daemon/tcp-test.log
> --- test/daemon/tcp-test.log.chk        2015-01-15 01:05:00.332640025 -0800
> +++ /tmp/gpsd-test-cgo5DxwR9VfFTg/test-1750.chk 2015-01-23 14:54:06.876014515 
> -0800
> @@ -4,8 +4,3 @@
>  {"class":"TPV","mode":3,"lat":20.628798667,"lon":-87.068079667,"alt":-30.400,
> "epv":69.000}^M
>  $GPGSV,3,1,12,28,14,150,41,09,15,254,41,10,43,192,47,13,06,081,36*7A
>  $GPGSV,3,2,12,02,56,323,,04,41,024,,12,31,317,,17,31,085,*72
> -$GPGSV,3,3,12,05,15,318,,24,02,246,,33,08,096,,35,45,118,*7D
> -{"class":"SKY","xdop":0.76,"ydop":1.60,"vdop":3.00,"tdop":0.99,"hdop":1.70,"g
> dop":3.70,"pdop":3.40,"satellites":[{"PRN":28,"el":14,"az":150,"ss":41,"used":
> true},{"PRN":9,"el":15,"az":254,"ss":41,"used":true},{"PRN":10,"el":43,"az":19
> 2,"ss":47,"used":true},{"PRN":13,"el":6,"az":81,"ss":36,"used":true},{"PRN":2,
> "el":56,"az":323,"ss":0,"used":false},{"PRN":4,"el":41,"az":24,"ss":0,"used":f
> alse},{"PRN":12,"el":31,"az":317,"ss":0,"used":false},{"PRN":17,"el":31,"az":8
> 5,"ss":0,"used":false},{"PRN":5,"el":15,"az":318,"ss":0,"used":false},{"PRN":2
> 4,"el":2,"az":246,"ss":0,"used":false},{"PRN":120,"el":8,"az":96,"ss":0,"used"
> :false},{"PRN":122,"el":45,"az":118,"ss":0,"used":false}]}^M
> -$GPRMC,193221.00,A,2037.7279,N,08704.0848,W,00.1,201.8,231207,01,W,A*2D
> -{"class":"TPV","mode":3,"time":"2007-12-23T19:32:21.000Z","ept":0.005,"lat":2
> 0.628798333,"lon":-87.068080000,"alt":-30.400,"epx":11.444,"epy":24.060,"epv":
> 69.000,"track":201.8000,"speed":0.051}^M
> -$GPZDA,193223.00,23,12,2007,00,00*69
> Processing test/daemon/tcp-torture.log

Any time you see a test failure that consists of a solid stretch of omitted
lines, that's the address@hidden timing problem.  You should be able to make it 
go away
by increasing the WRITE_PAD and CLOSE_DELAY values in gps/fake.py.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]