#10 gpsdrive leaks memory at 7mb/hr

[Hamish B]

Hi,

I have noticed that if I leave gpsdrive running for a long time (overnight) that it leaks a significant amount of memory. Even with show-track turned off.

For some strange reason it slowed from 7.3 to 1.5 MB/hr after 3.5 hours.

valgrind memcheck log and memory use graph attached.

I'm currently running valgrind's massif tool which should make a nice graph showing the functions using the memory.

Hamish

[Hamish B]

mem use vs. time

[Hamish B]

valgrind memcheck log

[Hamish B]

File Added: valgrind_memcheck.log

[Hamish B]

File Added: massif.5932.html

[Hamish B]

valgrind's massif analysis of heap usage

[Hamish B]

File Added: massif.5932.png

[Hamish B]

valgrind's massif analysis of heap usage (run for 30min)

[Hamish B]

valgrind showed that the worst offender was the g_malloc() called from gdk_pixbuf_new(). (see the massif.html attachment)

secondary was three calls to g_malloc0() from main(), the 3 together adding up in maginitude to about the same leakage rate as the primary offender.

I let it run for about 30 minutes, with no GPS attached.
command used was:
$ valgrind --tool=massif --format=html gpsdrive

Hamish

[Hamish B]

Guenther wrote:
> 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.

I put a debug message, there, it seems tempimage is
only allocated once. I tested on a stationary computer,
so not much switching maps, but I did switch to pos.mode and zoom in/out to get other maps to draw.

So I think this one sticks out simply because it is quite big. It is "freed" when the program ends.
[1280x1024x6 is very close 7,943,652 bytes reported by valgrind]

I ran "ps aux" in a loop to watch it grow. It grows at
about 1.73 bytes/second (way more than expected for a few lat,lon,course doubles @ 1 Hz NMEA blocks), and the increases occur every 15 seconds. I had a look at gpsdrive.c, the two 15 sec g_timeout_add()s were for poi_rebuild_list() and friends_agent(). I changed poi_rebuild_list() to refresh every 25 sec, and then instead of 24 or 28 bytes every 15sec the mem use was 44 bytes every 25sec.

So something in poi_rebuild_list().

I had a look, and thought I found something in poi.c line 401 -- the g_free() should be in the while loop I think:

Index: src/poi.c

--- src/poi.c (revision 2074)
+++ src/poi.c (working copy)
@@ -398,14 +398,13 @@
g_strlcat (local_config.poi_filter,
t_config, sizeof (local_config.poi_filter));
}
+ g_free (t_name);
}
while (gtk_tree_model_iter_next
(GTK_TREE_MODEL (poi_types_tree), &t_iter));

g_strlcat (t_filter, "1)", sizeof (t_filter));

- g_free (t_name);
-
current.needtosave = TRUE;

db_get_visible_poi_types (t_filter);

but no luck, the memory is still badly leaking at approximately the same rate.

Perhaps the above is still an error though? Little leaks should be stopped too.

Hamish

[Hamish B]

TOOLS:

bash loop to record memory use, the 5th column is the relevant one:

while [ 1 -eq 1 ] ; do
ps aux | grep [g]psdrive >> gpsdrive_mem_5min.log
sleep 300
done

this one will cut out the 5th column and apply line numbers (I ran this with "sleep 1" so line numbers = elapsed seconds)

cat gpsdrive_mem_1sec_B.log | grep -v 'less gpsdrive.c' | \ awk '{print $5}' | nl > gpsdrive_mem_1sec_B.dat

Hamish

[Hamish B]

I just fixed a few minor mem leaks with r2078, mostly wtr PangoFontDescription.

The biggest ones 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.

Do those each need gdk_pixbuf_unref() to close? I am not sure, but it's the closest name to "gdk_pixbuf_free()" I could find.

I notice that while gdk_pixbuf_unref() is used in some parts of the code it is behind "#ifndef GDK_PIXBUF_DISABLE_DEPRECATED", so apparently not something to start adding.. ??

Hamish