GNOME Bugzilla – Bug 680144
gstreamer 0.10.36 has memory leak issue
Last modified: 2012-10-17 13:50:35 UTC
I setup rygel as render only, send mp3 from W7 media player with ONE MP3 , repeatedly. The main memory on my target system will decrease to about 700KB for one night. Originally the main memory is about 45MB free, After a lot of transitions from PLAYING --->STOPPED, and then PLAYING, Free memory on my target system will reduce bit by bit. Does anyon have idea about the issue? The version i used: gstreamer 0.10.36 glib-2.32.3 gssdp-0.12.1 gst-plugins-base-0.10.36 gst-plugins-good-0.10.31 gst-plugins-ugly-0.10.19 gupnp-0.18.3 gupnp-av-0.10.2 gupnp-dlna-0.6.6 rygel-0.14.1
Please provide EXACT steps how to reproduce and how exactly to measure this.
What makes you think GStreamer is leaking the memory, and not, say, rygel or gupnp? I would suggest you run the same test on a desktop system, and run it through G_SLICE=always-malloc valgrind --leak-check=yes rygel to see what leaks where.
Because When I use gstreamer-0.10.35 to do the same testing for several hours. The main memory of my target system does not reduce. I will do the verification that you mentioned in next.
Perhaps you could also try GStreamer core git (0.10 branch) for comparison? It might already have been fixed.
When I change the package below : gstreamer 0.10.35 gst-plugins-base-0.10.35 gst-plugins-good-0.10.30 gst-plugins-ugly-0.10.18 , then the main memory of my target system does not reduce. Could you explain more detail about 0.10 branch? Where I can check the 0.10.x branch? Can I just change one of the package, respectively for verification? That is to say: Does it must to use gst-plugins-base-0.10.35 when I use gstreamer 0.10.35? Because I see the release date are the same for all package that I mention above.
Created attachment 219087 [details] gstreamer-0.10.36 memory leak log
hi here is the log data about memory leak phenomenon. time duration is about 50 minutes. system memory used : 25232KB ------> 29508KB memory that occupied by rygel when playing 40.3% ----> 45.2%
You can change some packages upwards, but only in one direction. Older base/good/ugly packages should (theoretically) continue to work fine if you just upgrade GStreamer core from 0.10.35 to 0.10.36. So what you could try is: start with core/base .35, good .31, ugly .19, then: - upgrade core to .36, retest - upgrade base to .36, retest - upgrade good to .31, retest - upgrade ugly to .19, retest However, in practice the assumption is that core/base are always of the same version, and modules released at the same time are used together, so there's no guarantee this is going to work, but it might. A valgrind leak log from a desktop system would still also be useful. (Make sure to install -dbg packages for libc, glib, gstreamer libraries and gstreamer plugins before running valgrind).
(In reply to comment #6) > Created an attachment (id=219087) [details] > gstreamer-0.10.36 memory leak log This is not a valgrind leak log, but a log from rygel, which is not so useful here unfortunately. I don't see any valgrind output at all in this log, perhaps it got diverted, or you only captured stdout (>foo.log) and not stderr (2>foo.log)?
hi, valgrind may not run on our embedded platform. Since the configure process has error when I try to compile valgrind with our toolchain. I will try again. And BTW, I will try the 0.10 branch from git again. Thanks!
> valgrind may not run on our embedded platform That's why I suggested running it on a desktop system that uses the same versions.
(In reply to comment #9) > (In reply to comment #6) > > Created an attachment (id=219087) [details] [details] > > gstreamer-0.10.36 memory leak log > > This is not a valgrind leak log, but a log from rygel, which is not so useful > here unfortunately. I don't see any valgrind output at all in this log, perhaps > it got diverted, or you only captured stdout (>foo.log) and not stderr > (2>foo.log)? hi, could you have idea about GST_DEBUG setting when I log the valgrind? can I set export GST_DEBUG=playbin2:9?
You can, yes, but it's not gonna help with anything, it just adds noise, so I don't know why you'd want to do that.
(In reply to comment #13) > You can, yes, but it's not gonna help with anything, it just adds noise, so I > don't know why you'd want to do that. It seems no any message in the output file so far. Does it mean no memory leak if no any message in the output file?
No, it means something is not right. It should look similar to this (the ===12345=== bits are from valgrind): $ G_SLICE=always-malloc valgrind --leak-check=yes --trace-children=yes /bin/ls /does/not/exist ==16459== Memcheck, a memory error detector ==16459== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==16459== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==16459== Command: /bin/ls /does/not/exist ==16459== /bin/ls: cannot access /does/not/exist: No such file or directory ==16459== ==16459== HEAP SUMMARY: ==16459== in use at exit: 19,312 bytes in 3 blocks ==16459== total heap usage: 100 allocs, 97 frees, 32,216 bytes allocated ==16459== ==16459== LEAK SUMMARY: ==16459== definitely lost: 0 bytes in 0 blocks ==16459== indirectly lost: 0 bytes in 0 blocks ==16459== possibly lost: 0 bytes in 0 blocks ==16459== still reachable: 19,312 bytes in 3 blocks ==16459== suppressed: 0 bytes in 0 blocks ==16459== Reachable blocks (those to which a pointer was found) are not shown. ==16459== To see them, rerun with: --leak-check=full --show-reachable=yes ==16459== ==16459== For counts of detected and suppressed errors, rerun with: -v ==16459== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
Created attachment 219317 [details] new log data about memory leak new log data about memory leak
(In reply to comment #8) > You can change some packages upwards, but only in one direction. Older > base/good/ugly packages should (theoretically) continue to work fine if you > just upgrade GStreamer core from 0.10.35 to 0.10.36. > > So what you could try is: start with core/base .35, good .31, ugly .19, then: > > - upgrade core to .36, retest > - upgrade base to .36, retest > - upgrade good to .31, retest > - upgrade ugly to .19, retest > > However, in practice the assumption is that core/base are always of the same > version, and modules released at the same time are used together, so there's no > guarantee this is going to work, but it might. > > A valgrind leak log from a desktop system would still also be useful. (Make > sure to install -dbg packages for libc, glib, gstreamer libraries and gstreamer > plugins before running valgrind). Hi, there are some library not built by myself. Because that are included in toolchain of our platform. Like libc, libpthread, libm,etc... And, the other question: basically, rygel is a daemon, when rygel run playback, it will start multiple threads, when playback is reach end, then the threads will exit, the transition will repeatedly for a lot times, but the main thread are not exit. if the child thread allocate memory, but it does not free, and the parent thread is not exit. the memory will not free the system ,right? is the idea correct? in desktop , library are different with our target platform, like libc, libpthread, libm, etc...
(In reply to comment #8) > You can change some packages upwards, but only in one direction. Older > base/good/ugly packages should (theoretically) continue to work fine if you > just upgrade GStreamer core from 0.10.35 to 0.10.36. > > So what you could try is: start with core/base .35, good .31, ugly .19, then: > > - upgrade core to .36, retest > - upgrade base to .36, retest > - upgrade good to .31, retest > - upgrade ugly to .19, retest > > However, in practice the assumption is that core/base are always of the same > version, and modules released at the same time are used together, so there's no > guarantee this is going to work, but it might. > > A valgrind leak log from a desktop system would still also be useful. (Make > sure to install -dbg packages for libc, glib, gstreamer libraries and gstreamer > plugins before running valgrind). Hi, I have test 2 case: 1. core 36, base 35, good 30, ugly 18: the variation of free memory is not violent for about 6.5 hours 2. core 36, base 36, good 30, ugly 18: the variation of free memory is decrease about 3MB in 30minutes time duration. I can not use base 35 for good and ugly, since the configure procedure will get error. base 36 has memory leek issue on our platform. Even there is no memory leak message on desktop platform fo far. Do you have any idea about debugging base 36??
(In reply to comment #15) > No, it means something is not right. It should look similar to this (the > ===12345=== bits are from valgrind): > > $ G_SLICE=always-malloc valgrind --leak-check=yes --trace-children=yes /bin/ls > /does/not/exist > ==16459== Memcheck, a memory error detector > ==16459== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==16459== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==16459== Command: /bin/ls /does/not/exist > ==16459== > /bin/ls: cannot access /does/not/exist: No such file or directory > ==16459== > ==16459== HEAP SUMMARY: > ==16459== in use at exit: 19,312 bytes in 3 blocks > ==16459== total heap usage: 100 allocs, 97 frees, 32,216 bytes allocated > ==16459== > ==16459== LEAK SUMMARY: > ==16459== definitely lost: 0 bytes in 0 blocks > ==16459== indirectly lost: 0 bytes in 0 blocks > ==16459== possibly lost: 0 bytes in 0 blocks > ==16459== still reachable: 19,312 bytes in 3 blocks > ==16459== suppressed: 0 bytes in 0 blocks > ==16459== Reachable blocks (those to which a pointer was found) are not shown. > ==16459== To see them, rerun with: --leak-check=full --show-reachable=yes > ==16459== > ==16459== For counts of detected and suppressed errors, rerun with: -v > ==16459== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) Hi, After a period of observation, in desktop test case, the free memory is descreasing, 8MB for about 3 hours, from the output of "top" utility this is the same trend as our embedded platform, it seems beas 0.10.36 has memory leak issue, Do you know any bug fix about memory leak for base 0.10.36? Thanks !
[Please avoid fullquotes of previous comments, for the sake of readability.] (In reply to comment #16) > Created an attachment (id=219317) [details] > new log data about memory leak That is still not a valgrind log. See http://valgrind.org/docs/manual/QuickStart.html > Do you know any bug fix about memory leak for base 0.10.36? "git log" is your friend. :)
Created attachment 219450 [details] desktop memory leak issue by 0.10.36 the result is "out of memory" in desktop test case
Hi, the attached is the error log from valgrind in desktop test case. the result is out of memory. Could you provide some comment about memory leak issue by 0.10.36? thanks!
hi, I have try to build valgrind for my target embedd system. But the code size of valgrind is too big then rom size of my target embedd system. It is impossible to put valgrind on my target embedd system. And how about the error from destop test case? It seems the memory size that rygel occupied is increase, then system will detect the max limit the process can used. Rygel will be killed. This is the problem why free memory size is decreasing. when rygel set to PLAYING state ==> start new threads, when rygel set to STOPPED state==> stop the threads after a lot of the transition, the system memory will be occupied, is it cause by glib?since there is a thread wrapper from glib. Do you have any idea?
(In reply to comment #20) > [Please avoid fullquotes of previous comments, for the sake of readability.] > > (In reply to comment #16) > > Created an attachment (id=219317) [details] [details] > > new log data about memory leak > > That is still not a valgrind log. See > http://valgrind.org/docs/manual/QuickStart.html > > > Do you know any bug fix about memory leak for base 0.10.36? > > "git log" is your friend. :) Hi, Sir, the next I will attached the log by desktop test case. Could you kindly help to analyze the log data ? It seems memory leak is existence in 0.10.36 version. I deeply appreciated help for parsing the log data to figure out when is the code cause memory leak. Since gstreamer is very complicated for me. Thanks!
Created attachment 219568 [details] new log data about memory leak 0.10.36-20120724 new log data about memory leak 0.10.36-20120724
(In reply to comment #24) > (In reply to comment #20) > > [Please avoid fullquotes of previous comments, for the sake of readability.] > > > > (In reply to comment #16) > > > Created an attachment (id=219317) [details] [details] [details] > > > new log data about memory leak > > > > That is still not a valgrind log. See > > http://valgrind.org/docs/manual/QuickStart.html > > > > > Do you know any bug fix about memory leak for base 0.10.36? > > > > "git log" is your friend. :) > > Hi, Sir, > > the next I will attached the log by desktop test case. > Could you kindly help to analyze the log data ? > It seems memory leak is existence in 0.10.36 version. > I deeply appreciated help for parsing the log data to figure out when is the > code > cause memory leak. Since gstreamer is very complicated for me. > > Thanks! hi, Sir, the attached is another test with valgrind tool. Is it possible cause by library intl? or other library? thanks!
Created attachment 219575 [details] Another memory leak log from valgrind Another memory leak log from valgrind For example: ==14433== 11,636 (1,200 direct, 10,436 indirect) bytes in 2 blocks are definitely lost in loss record 8,485 of 8,489 ==14433== at 0x402860A: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==14433== by 0x463BBC4: g_malloc (gmem.c:159) ==14433== by 0x4651BB2: g_slice_alloc (gslice.c:1003) ==14433== by 0x46520D4: g_slice_alloc0 (gslice.c:1029) ==14433== by 0x45D7C0F: g_type_create_instance (gtype.c:1872) ==14433== by 0x45B9C61: g_object_constructor (gobject.c:1849) ==14433== by 0x45BB450: g_object_newv (gobject.c:1713) ==14433== by 0x45BBD87: g_object_new_valist (gobject.c:1830) ==14433== by 0x45BBEA6: g_object_new (gobject.c:1545) ==14433== by 0x435AEAA: gst_element_factory_create (gstelementfactory.c:386) ==14433== by 0x435B26F: gst_element_factory_make (gstelementfactory.c:457) ==14433== by 0x6694B4E: gst_play_sink_convert_bin_add_conversion_element_factory (gstplaysinkconvertbin.c:118) ==14433==
This last valgrind log entry looks interesting and useful. It looks like this may already have been fixed in git (0.10 branch): http://cgit.freedesktop.org/gstreamer/gst-plugins-base/log/gst/playback/gstplaysinkconvertbin.c?h=0.10 http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/gst/playback/gstplaysinkconvertbin.c?h=0.10&id=5462536a36f4bd78950298a694ced44468e6b4ae Any chance you could try that patch and see if it fixes your issue?
(In reply to comment #28) > This last valgrind log entry looks interesting and useful. > > It looks like this may already have been fixed in git (0.10 branch): > http://cgit.freedesktop.org/gstreamer/gst-plugins-base/log/gst/playback/gstplaysinkconvertbin.c?h=0.10 > > http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/gst/playback/gstplaysinkconvertbin.c?h=0.10&id=5462536a36f4bd78950298a694ced44468e6b4ae > > Any chance you could try that patch and see if it fixes your issue? Hi, Sir, But I have try the branch-0.10, that includes: gstreamer--->branch 0.10 base plugin --->branch 0.10 good plugin --->branch 0.10 ugly plugin ---->branch 0.10, and glib 2.32.3 change to 2.32.4, the result is the same, the issue still exist, =================================== or do you mean, I can just patch the specific file only? Not apply whole branch, right? And, If I would like to apply patch , which error from valgrind is necessary to patch? Should I select "definitely lost" item from valgrind log to patch?
AGAIN: Please avoid unneeded full quotes for the sake of readability!!! (In reply to comment #29) > But I have try the branch-0.10, that includes: > gstreamer--->branch 0.10 > base plugin --->branch 0.10 > good plugin --->branch 0.10 > ugly plugin ---->branch 0.10, > and > glib 2.32.3 change to 2.32.4, This means that you got the code from the code repository, instead of tarballs? The patches that Tim mentioned are in the code repository. > or do you mean, I can just patch the specific file only? > Not apply whole branch, right? A patch always fixes specific problems which are located in specific files. The information which specific files will receive the change is included in the patch itself. Also see http://en.wikipedia.org/wiki/Patch_%28computing%29 > If I would like to apply patch , which error from valgrind is necessary to > patch? None. You patch the gst-plugins-base source code, not valgrind. See above.
(In reply to comment #30) > AGAIN: Please avoid unneeded full quotes for the sake of readability!!! > > (In reply to comment #29) > > But I have try the branch-0.10, that includes: > > gstreamer--->branch 0.10 > > base plugin --->branch 0.10 > > good plugin --->branch 0.10 > > ugly plugin ---->branch 0.10, > > and > > glib 2.32.3 change to 2.32.4, > > This means that you got the code from the code repository, instead of tarballs? > The patches that Tim mentioned are in the code repository. > > > or do you mean, I can just patch the specific file only? > > Not apply whole branch, right? > > A patch always fixes specific problems which are located in specific files. The > information which specific files will receive the change is included in the > patch itself. Also see http://en.wikipedia.org/wiki/Patch_%28computing%29 > > > If I would like to apply patch , which error from valgrind is necessary to > > patch? > > None. You patch the gst-plugins-base source code, not valgrind. See above. Hi, Sir, my meaning is which kind of log data should be take care from valgrind? Since I would like to fix memory leak issue. There are a lot of items from valgrind log data, per your rich experience, which item in valgrind log is high priority should be take care? Thanks!
I tell you for the third time now: Please avoid unneeded full quotes of previous comments. Please read this comment. Please understand this comment. Thanks.
hi, I am sorry! I just click "reply" to input my comments for the comments. So, Should I just write comment in Additional comments field,right?
I believe this bug is obsolete as per comment #29, so let's close it.