GNOME Bugzilla – Bug 149162
Importing m4a files in Rhythmbox leaks memory
Last modified: 2005-01-18 14:12:59 UTC
1) Open Rhythmbox and Import a directory containing m4a files. 2) Rhythmbox memory usage skyrockets. I brought this up to the RB developers and they said that it is probably a problem in the gst-plugin. I am using RB 0.8.4 gstreamer 0.8.3 and gst-plugins 0.8.2 with gst-plugin-faad 0.8.2
Is this still an issue with latest updates? Been lot of memory leak fixes recently, so hopefully this one is taken care of.
And if you still get it, could you run it under valgrind so we see *what* eats memory for you? Thanks!
I'll give it a try. What qualifies as "latest-updates". CVS? Last release? If it persists, I'll see if I can get valgrind output. Any special valgrind tool you would like or just memtool?
Just memtool would help a great deal. Latest release of gst-plugins is good enough, no need to use CVS.
Created attachment 35002 [details] strange valgrind output This is the output I got from running rhythmbox with the 0.8.6 gst-plugins under valgrind --tool=memcheck --leak-check=yes --show-reachable=yes. Lots of complaining about thread functions no-ops. This doesn't really help this bug any, but the valgrind faq and google were utterly unhelpful in determining how to fix this. Any ideas on how to get a more useful valgrind output?
I need the start of the log. Anything after the first few warnings is uninteresting, most of the times.
Created attachment 35003 [details] complete valgrind output Ok, here is the complete output. Rhythmbox starts with an empty song list. I open try to import a directory with m4a files in it (usually causes the leak) and it crashes. Please let me know if there is a more useful way I can run valgrind. Thanks for the help.
What OS do you use? Your RB is having issues before any GStreamer function is called, and crashes on memory issues in libORBit. If this is Gentoo or some LFS sort of thing, please update to stable versions (known-good) of those packages and try again. I can't see any memleaks in GStreamer using this, unfortunately. If it's Fedora or Novell, let me know and I'll slap the person in charge of those packages. ;).
This was my point about running valgrind. I am using Gentoo with rhythmbox 0.8.8 which is just the compiled source from the actual release. When I run rb normally, it runs fine and when I try to import m4a files I get to the memory leak. However if I run it under valgrind, it runs painfully slowly, gives the output I sent you and crashes when I import the folder. That's why I was worried about the validity of the test since it runs differently that normal. Also, this behavior has been consistent since rb ~0.8.4 when I first tried importing m4a's and several versions of pst-plugins.
Right. I don't know how to debug memory leaks otherwise than using valgrind, because we're seriously looking in an impossibly big pile of code (RB + GStreamer a as a whole isn't exactly hello world), and there's very few, if any, persons that know all this code together... Can you try upgrading or downgrading libORBit and see if that improves the crash? Also, make sure not to use any weird compiler flags.
I tried a variety of things and nothing seemed to change the bahavior. If i might suggest, if you would know where to look for this sort of thing you might try downloading iTunes, ripping a cd, copying the resulting files a few times to get a few hundred megs of m4a's and import them into Rhythmbox. I'm serious, this is a several hundred MB memory leak, you can't miss it. you might then be more successful running valgrind that I was. Sorry I can't be of more help. If it matters, even with the leak m4a's are now importing (gst-plugins 0.8.7) into Rhythmbox although the genre and track numbers of the tags do not import correctly. The track number is blank and the genre is Unknown even though other players can read the tags. But this may be another bug for another time. Thanks for the help.
Tags are fixed in CVS. Iĺl see if I can get it to leak.
Created attachment 36147 [details] [review] valid valgrind log this is valgrind on current CVS, with --show-reachables=yes --leak-check=yes. Pipeline is: "valgrind --tool=memcheck --show-reachable=yes --num-callers=20 --leak-check=yes ~/Projects/GStreamer/gstreamer/tools/.libs/gst-launch-0.8 filesrc location=file.m4a ! qtdemux .audio_00 ! faad ! audioconvert ! fakesink" 1-5, 8-11, 13-19 are dynamic lib loading, registry or global initializers. 6 is a leaked string, fixed in CVS. 7 doesn't exist (?) 12 is a taglist leak, fixed in CVS. I don't see any big numbers here. I'll try Rhythmbox next... Maybe partial pipeline processing is different...
Thanks for looking into this. Be careful importing with rhythmbox. It will continue to use memory until your desktop freezes if you are importing enough m4a's at once.
Rhythmbox seems to not run under valgrind at all... Nice... OK, I did some more tests, and apparently, qtdemux indeed does not clean up anything from it's header reading. Not the header (moov) buffer, not the node tree, not the streams, nothing. I added that, and memory eating went down from >50MB (for 100 songs) to 2 MB. I think 2 MB is reasonable, because this was initialized right away when reading starts, it doesn't increase when loading the songs. I think I can therefore mark this fixed. Not very scientific, but that's the tools I'm stuck with. ;). Note: there may be more memory leaks that I'm not aware of. Those are, however, small. I can't see any obvious ones, and I can't valgrind RB to test. So that's why I leave it at this for now.
That is truly spectacular news. Thank you for looking into this issue. When might I see the fruits of your labor in a gst-plugins release?
The current CVS requires a new gstreamer core release (some newly added functions), so assuming that'll take another 2 weeks, gst-plugins will take another 4 weeks or so, I'd say.