[ gpsdrive ] bug [ 2124271 ] gpsdrive leaks memory at 7mb/hr

[Guenther Meyer]

Am Sonntag 28 September 2008 schrieb Hamish:
> [cc'd from the bug report]
>   http://sourceforge.net/tracker/?group_id=148048
>
>
> I just fixed a few minor memory leaks with r2078, mostly wtr
> PangoFontDescription.
>
great!

> The biggest leaks are still out there.
>
> Figuring the only thing that could leak 1.75kb/sec was graphics or glyphs,
> I was trying to follow GdkPixBuf* allocations. (*icon seems to come up in
> valgrind reports..?)
>
> Do those each need gdk_pixbuf_unref() to free? I am not sure, but it's
> the closest name to "gdk_pixbuf_free()" that I could find.
> (I have very little GTK experience)
>
I'll have to have a look at that.

> I notice that while gdk_pixbuf_unref() is used in some parts of the code
> it is behind "#ifndef GDK_PIXBUF_DISABLE_DEPRECATED" in the header file,
> so apparently not something to start adding into the code as new..   ??
>
I don't know who wrote this that way, and why...

> "g_free(tempimage)" seems to be wrong. It is only allocated once AFAICT
> and so not actually progressively leaking after the initial allocation. I
> think freeing it at the end of expose_cb() is wrong as it gets reused the
> next time the fn runs. Putting g_free(tempimage) at the end of main()
> causes valgrind to complain about an invalid free, and doesn't help the
> final abandonment score any.
>
right. at first sight this seemed to be the culprit. but it wasn't.
I didn't write this code, but it looks a little bit strange to me, how the map 
drawing is done. but it works, so I didn't change it.
maybe someone has to check this, also all the timeout and expose functions. I 
guess there is still some place for optimization.



-------------- 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/20080928/daa0ae0b/attachment.bin>