GNOME Bugzilla – Bug 581790
memory leak when changing state from ready to playing to ready
Last modified: 2009-09-02 16:44:10 UTC
Using pygst, when changing state from ready to playing in a loop, a memory leak appears. When going to null instead of ready, there is no problem. I will attach some simple test code for this. (In my application, I need to use 'ready' instead of 'null' so that I can change filesrc's without interrupting streaming (shout2send)).
Created attachment 134220 [details] simple test with leak
How do you detect the memory leak with Python? Valgrind with suppression file / pymalloc disabled? The example script gives me the following warning but runs nevertheless: AttributeError: 'module' object has no attribute 'Element' Any ideas what causes this? My Python version: 2.6.2+
not sure, this is beyond my programming abilities at the moment. i'm just using ps to watch the memory leak but I haven't attempted to do more to track it down. i was hoping someone with more experience would be able to see what's going on more quickly :). my python version is also 2.6.2. not sure where your warning is coming from (unable to reproduce). cheers :).
Created attachment 142300 [details] C version of the first test case. I had some issues with my python, which disappeared after upgrading packages. Meanwhile, I rewrote the example with C. I can observe that the memory consumption (ps aux, RSS field) raises steadily when you keep changing the states in a loop. The additional memory is not freed when the pipeline is destructed. I don't think there is any major leaks since you really have to change the state hundreds or thousands times to see any significant effect, but it still puzzles me. Valgrind didn't tell me clearly what could be the problem. there are some possibly leaks/still reachable memory, but not enough to cover the memory addition. I run it like: $ valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./test 1000 Maybe someone else can come up with better ideas with the C test case.
I can't confirm this, there's almost no memory leak (the only ones that I see are in libasound and those are small). You might want to run without --show-reachable=yes, there are many reachable memory locations that really should be there ;)
Created attachment 142310 [details] valgrind log with current-ish git This is what I get. No major leaks. Not quite sure what to make of the last two items, but it looks like it may just be internal caches. A gst_task_cleanup_all() didn't make too much difference either.
Created attachment 142317 [details] Bash script to read RSS values from a process The attached script should show how the resident set size increases when the state is looped. I believe this was the reporter's initial concern as said in comment 3. This is what I'm seeing with the script when running with 1000 iterations. The first value is: RSS: 5480 and the last value: RSS: 10592 So, it *seems* that additional memory is used somewhere, even though there may not be actual leaks.
You might want to use valgrind's massif tool to get full details of memory consumption over time. The problem is that if it's a small leak... you'll have to activate very low granularity... and then dig out what increased through time.
Ran it in massif. It only seems to be 'leaking' the messages on the bus (basically nobody is picking them up so they continously stash up). So you should either: * connect to the bus (whether asynchronously or synchronously) * or set the bus to flushing when the pipeline is >= READY closing bug.
works beautifully, thanks for your help!