Tue 23 Oct 2012 03:25:35 PM UTC, comment #3:
The segfault happens in gpsmon, not gpsfake. gpsdecode happily
ignores the unrecognized records.
To reproduce, in one terminal window run 'gpsfake -i bad.log' and in another run gpsmon. Advance through a few records in the gpsfake window and gpsmon will segfault.
I just tried it again with the GIT head and the problem still happens. I'm running Ubuntu 12.05.
Thanks.
|
Tue 23 Oct 2012 02:39:54 PM UTC, comment #2:
I attempted to reproduce this behavior with git head and the following command:
gpsfake -1 -g <bad.log
but I couldn't replicate it. What was the exact command you used?
Please try reproducing with git head.
Also, please try reproducing by running the bad log through gpsdecode. From the error pattern this is almost certainly a problem in driver_nmea.c, and that utility exercises the NMEA decoder ditectly while avoiding the additional complexity of gpsfake and the gpsd toplevel.
|
Thu 27 Sep 2012 08:23:31 PM UTC, original submission:
The GlobalTop MT3339 GPS chip includes a capability to record GPS fixes in flash for later retrieval. The download request is made via a proprietary NMEA packet "$PMTK622,1*29".
The results look like:
$PMTKLOX,1,40,A8FD6050,02BB3E4C,428F3FE4,C2490437,B7FD6050,02BE3E4C,428D3FE4,C2470421,C6FD6050,02BC3E4C,42893FE4,C2440455,D5FD6050,027D3E4C,428A3FE4,C2420482,14FE6050,02A63E4C,427C3FE4,C240046F,23FE6050,02903E4C,428E3FE4,C240049C*17
A few are contained in the attached file.
gpsmon segfaults when it encounters these PMTKLOX packets. Using gpsfake in one-step mode it appears to happen on the third packet.
|