After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 577667 - Streaming video memory-leaks 100% of the streamed data.
Streaming video memory-leaks 100% of the streamed data.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: common
0.10.22
Other Linux
: Normal major
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 546673 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-01 23:37 UTC by Dekar
Modified: 2009-08-10 23:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dekar 2009-04-01 23:37:16 UTC
It took me some time to find out what produces those leaks, first I only realized that after a day or two banshee uses 1,5gb ram (My laptop has 2gb). It can be easily reproduced by streaming some podcasts. Just play several streams for about an hour and banshee will use up 500-600mb ram (in case of video podcasts). I marked this major since it totally slows my system down after a day and I have to close banshee.
Comment 1 Gabriel Burt 2009-04-01 23:59:06 UTC
Sebastian, this sound like anything you've heard of in GStreamer land, or like a possible bug in it?

Dekar, are there podcasts where this isn't reproducible?  If so, can you give a URL to one that is and one that isn't?
Comment 2 Dekar 2009-04-02 00:33:57 UTC
I have tried several versions of banshee, that doesn't change anything.
To test it I have used the German Galileo podcast, but it seems to happen for any podcast. I can watch the memory usage increase in 0.1mb steps every 1-2 seconds.
At the moment I am at 831mb - and counting ;)

That one should leak for sure:
http://www.prosieben.de/podcast/galileo/index.xml

I didn't watch my memory while streaming audio podcasts so far since I download them usually. But I will check that tomorrow.

Some older screenshot I've also attached to the mailing list some weeks ago.
http://f.imagehost.org/0742/Screenshot-System_Monitor-1.png
Comment 3 Dekar 2009-04-04 08:36:49 UTC
I've listened to an audio podcast which I streamed and it didn't leak, at least not nearly as much as it downloaded. (ram usage increased by a few kb, the file had ~50mb) It seems to leak only for video podcasts. I looked for some other players, but I couldn't find any FOSS player that plays video podcasts. (I left out amarok, maybe it could do that...) Banshee is the best anyway, so I'd really appreciate if you can get that fixed!
Comment 4 Bertrand Lorentz 2009-04-05 17:08:12 UTC
*** Bug 546673 has been marked as a duplicate of this bug. ***
Comment 5 Bertrand Lorentz 2009-04-05 18:26:25 UTC
I've seen a 50 MB increase after playing 10 minutes of one video of the above podcast.
Similar increase happens when playing directly with gstreamer :
gst-launch-0.10 playbin uri=http://pro7-galileo.feedplace.de/files/31032009_galileo_zuckermythen.mp4

Playing from a local file doesn't seem to cause any leak.

Here's what I think might be the relevant output of "valgrind --leak-check=yes gst-launch-0.10 playbin uri=http://pro7-galileo.feedplace.de/files/31032009_galileo_zuckermythen.mp4"

==32496== 520,388 bytes in 236 blocks are possibly lost in loss record 41 of 44
==32496==    at 0x400848F: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==32496==    by 0x4947DCD4: g_malloc (in /usr/lib/libglib-2.0.so.0.1800.4)
==32496==    by 0x4F1087F9: gst_adapter_take (in /usr/lib/libgstbase-0.10.so.0.19.0)
==32496==    by 0x4F16667: (within /usr/lib/gstreamer-0.10/libgstqtdemux.so)
==32496==    by 0x4F07221D: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F0729B2: gst_pad_push (in /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4695D98: (within /usr/lib/gstreamer-0.10/libgstcoreelements.so)
==32496==    by 0x4F07221D: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F0729B2: gst_pad_push (in /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F059E9C: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F07221D: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F0729B2: gst_pad_push (in /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496== 
==32496== 
==32496== 1,807,005 (1,362,951 direct, 444,054 indirect) bytes in 2,069 blocks are definitely lost in loss record 44 of 44
==32496==    at 0x400848F: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==32496==    by 0x4947DCD4: g_malloc (in /usr/lib/libglib-2.0.so.0.1800.4)
==32496==    by 0x4F1087F9: gst_adapter_take (in /usr/lib/libgstbase-0.10.so.0.19.0)
==32496==    by 0x4F16667: (within /usr/lib/gstreamer-0.10/libgstqtdemux.so)
==32496==    by 0x4F07221D: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F0729B2: gst_pad_push (in /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4695D98: (within /usr/lib/gstreamer-0.10/libgstcoreelements.so)
==32496==    by 0x4F07221D: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F0729B2: gst_pad_push (in /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F059E9C: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F07221D: (within /usr/lib/libgstreamer-0.10.so.0.19.0)
==32496==    by 0x4F0729B2: gst_pad_push (in /usr/lib/libgstreamer-0.10.so.0.19.0)
Comment 6 Sebastian Dröge (slomo) 2009-04-08 06:46:56 UTC
I can't reproduce this here with latest git. Could you install debug packages for libc, glib, gstreamer, gst-plugins-base and gst-plugins-good and run valgrind again? This way we get line numbers, etc :)

Also, which versions of the above packages are you using?
Comment 7 Bertrand Lorentz 2009-04-10 21:03:33 UTC
Here are the version that I have :
glibc 2.8_p20080602
glib 2.18.4
gstreamer 0.10.22
gst-plugins-base 0.10.22
gst-plugins-good 0.10.14

I'm on Gentoo, and no, I don't have the -f-leak-all-over gcc flag set ;)

Despite a long fight, I was not able to get valgrind to print line numbers. I did compile debug versions, to no avail.

I installed and ran the latest git with jhbuild, and I didnt see any leak either. So I guess this as already been fixed since the last release.