[ gpsdrive ] mem leak at 7mb/hr, bogus data in track.sav

[Guenther Meyer]

Am Dienstag 23 September 2008 schrieb Hamish:
> valgrind showed that the worst offender was the g_malloc() called from
> gdk_pixbuf_new(). (see the massif.html attachment) Presumably it just
> needs another g_free() somewhere??
>
probably the tempimage in expose_cb ().
reeeaaaally old code, I don't know really why this is done this way, but it 
seems to work.
I guess a "g_free (tempimage)" at the end of expose_cb () could help.

> The second: [ 2124308 ] track_*.sav full of 1001.0 junk data
>
> when GpsDrive loses view of satellites it still logs position with dummy
> 1001.0 coords (but real timestamp).
>
yes.

> why record this? it just wastes space.
> if there is a desire to indicate a break between a contiguous string of
> good fixes, maybe just insert one extra newline when the fix is first
> lost.
>
this results from the old track code.
when there is no valid position available, it records those values.
afaik the reason is, the points (or number of points) are necessary to 
calculate the trip data.

> the gpx logger seems to break these using <trkseg> within the same <trk>,
> which is nice. (or at least it breaks trkseg for some reason, I have to
> check if the times line up with .sav going to 1001.0s)
>
yes, that's newer code, that tries to handle this.
if it does not line up, then there is probably a bug somewhere.

> to get rid of it is all that is needed to modify storepoint() by
> replacing "add_trackpoint(1001.0, ...)" with ";" ? [src/track.c line 171]
>
that would break some things, I guess...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.gpsdrivers.org/pipermail/gpsdrive/attachments/20080923/7bc0f5c5/attachment.bin>