GNOME Bugzilla – Bug 568462
Memory leak? while downloading a lot of podcasts
Last modified: 2009-01-21 14:11:43 UTC
The memory gets full while downloading a lot of podcasts. When downloading a podcast the memory (monitored by "gnome-system-monitor") gets larger and larger and won't get cleared (or is it called 'flushed'?).
What version of rhythmbox are you using? Valgrind reports would be helpful in tracking this down. See http://live.gnome.org/Valgrind for more information on running gnome software in valgrind.
Created attachment 126908 [details] Valgrind log ran with rhythmbox -d I'm using Rhythmbox 0.11.6. I ran Valgrind for 3 minutes or so. Rhythmbox automatically starts downloading the podcast(s) on startup.
The only thing that looks at all suspicious is this: ==25976== 9,012 (8,480 direct, 532 indirect) bytes in 154 blocks are definitely lost in loss record 230 of 256 ==25976== at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==25976== by 0x50D0D63: g_malloc (gmem.c:131) ==25976== by 0x50EB45B: g_strconcat (gstrfuncs.c:259) ==25976== by 0x50B1683: g_filename_to_uri (gconvert.c:1559) ==25976== by 0x4CA81EF: g_local_file_get_uri (glocalfile.c:360) ==25976== by 0x4C8222B: g_file_get_uri (gfile.c:477) ==25976== by 0x408150F: (within /usr/lib/librhythmbox-core.so.0.0.0) ==25976== by 0x40816D0: (within /usr/lib/librhythmbox-core.so.0.0.0) ==25976== by 0x40A6679: (within /usr/lib/librhythmbox-core.so.0.0.0) ==25976== by 0x50C67C0: g_idle_dispatch (gmain.c:4235) ==25976== by 0x50C86F7: g_main_context_dispatch (gmain.c:2144) ==25976== by 0x50CBDA2: g_main_context_iterate (gmain.c:2778) ==25976== by 0x50CC2C1: g_main_loop_run (gmain.c:2986) ==25976== by 0x48CC3A8: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1400.4) ==25976== by 0x806327F: main (in /usr/bin/rhythmbox) Please install the debug symbols for rhythmbox ('rhythmbox-dbg' package on debian/ubuntu).
Created attachment 126914 [details] With debug symbols I guess these are the lines you're looking for: ==7105== at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==7105== by 0x50D0D63: g_malloc (gmem.c:131) ==7105== by 0x50EB45B: g_strconcat (gstrfuncs.c:259) ==7105== by 0x50B1683: g_filename_to_uri (gconvert.c:1559) ==7105== by 0x4CA81EF: g_local_file_get_uri (glocalfile.c:360) ==7105== by 0x4C8222B: g_file_get_uri (gfile.c:477) ==7105== by 0x408150F: actually_add_monitor (rhythmdb-monitor.c:133) ==7105== by 0x40816D0: monitor_subdirectory (rhythmdb-monitor.c:172) ==7105== by 0x40A6679: _recurse_async_idle_cb (rb-file-helpers.c:572) ==7105== by 0x50C67C0: g_idle_dispatch (gmain.c:4235) ==7105== by 0x50C86F7: g_main_context_dispatch (gmain.c:2144) ==7105== by 0x50CBDA2: g_main_context_iterate (gmain.c:2778) ==7105== by 0x50CC2C1: g_main_loop_run (gmain.c:2986) ==7105== by 0x48CC3A8: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1400.4) ==7105== by 0x806327F: main (main.c:330) I also found out that the leaking only occurs during the actual download. When my internet connection was lost no leaking occurred.
Well, I've fixed that: 2009-01-21 Jonathan Matthew <jonathan@d14n.org> * rhythmdb/rhythmdb-monitor.c: (actually_add_monitor): Don't get the file URI here - it wasn't used for anything, and we weren't freeing it. but that's not the cause of the problem here. What exactly is it that you're seeing in gnome-system-monitor that indicates a memory leak?
Well, when I look at the Resources tab at 'Memory and Swap History' the memory meter increases with 0.1 MiB every 2 seconds, while downloading a podcast. When downloading a lot of podcasts the memory doesn't get cleared. So after a while the memory gets full and I have to force my computer to shutdown.
Which process is growing? It sounds like it might be gvfsd-http rather than rhythmbox, which would indicate a bug in gvfs.
You're absolutely right! The gvfsd-http process is growing, not rhythmbox. Thanks for you help. I changed this bug report to Invalid.
That doesn't mean the bug report is invalid, it just means the bug isn't in rhythmbox. It could be in gvfs or libsoup, both of which are tracked in GNOME bugzilla. What versions of libsoup (libsoup2.4-* package on debian/ubuntu) and gvfs (gvfs-backends package) do you have?
This is almost certainly a duplicate of bug 551075.
Yes indeed, I think it's a duplicate of bug 551075. I use package libsoup2.4-1 version 2.24.1-0ubuntu1. For gvfs I use version 1.0.2-0ubuntu1. This bug is already listed on launchpad (https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225615) and (I think) solved in version 1.1.2 of gvfs (http://svn.gnome.org/viewvc/gvfs/trunk/NEWS?revision=2136&view=markup). I marked this bug report as invalid, because I didn't see the 'product' could be changed. I think the problem is solved?
Looks like it. Thanks for helping me fix the other leak, though. *** This bug has been marked as a duplicate of 551075 ***