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 573720 - [mp3parse] Memory leak when playing shoutcast streams
[mp3parse] Memory leak when playing shoutcast streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.x
Other All
: Normal normal
: 0.10.12
Assigned To: Michael Smith
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-02 08:34 UTC by J.Rios
Modified: 2009-08-05 21:03 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Valgrind totem log (13.37 KB, application/x-compressed-tar)
2009-03-02 17:21 UTC, J.Rios
  Details
Memoy used by totem when playing a shoutcast stream started (66.29 KB, image/png)
2009-03-03 08:10 UTC, J.Rios
  Details
Memoy used by totem after 6 hours playing a shoutcast stream (67.63 KB, image/png)
2009-03-03 08:11 UTC, J.Rios
  Details
Don't build the seektable if it's not seekable (2.11 KB, patch)
2009-04-20 20:27 UTC, Michael Smith
committed Details | Review

Description J.Rios 2009-03-02 08:34:05 UTC
Please describe the problem:
There is a memory leak when playing shoutcast streams. I have tested it with Totem, Rhythmbox and the application im working on.

Steps to reproduce:
1. Start the gstreamer application you prefer that support shoutcast streams like totem or rhythmbox
2. Add a shoutcast radio like http://64.71.145.130:8095
3. Start playing and note the used memory with system monitor
4. The memory used will be increased by about 1Mb each 2 mins


Actual results:
If you follow this steps you can see the memory is allocated and not freed and will take you the whole system mem in several hours

Expected results:
What I expected was that the memory used by gstream will be stable and freed once its played but its not happening. 

Does this happen every time?
Yes

Other information:
I have tested the application im developing with valgrind and shows this leaks points

==25840== 45,452 bytes in 908 blocks are possibly lost in loss record 230 of 244
==25840==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==25840==    by 0x700A23: g_malloc (gmem.c:131)
==25840==    by 0x717542: g_slice_alloc (gslice.c:824)
==25840==    by 0x717874: g_slice_alloc0 (gslice.c:833)
==25840==    by 0xC4C3EA: g_type_create_instance (gtype.c:1654)
==25840==    by 0x6F4E564: gst_mini_object_new (gstminiobject.c:181)
==25840==    by 0x6F4D399: gst_message_new_custom (gstmessage.c:285)
==25840==    by 0x6F4DB83: gst_message_new_buffering (gstmessage.c:478)
==25840==    by 0x62E92A0: check_queue (gstplaybasebin.c:524)
==25840==    by 0x6F8FD55: gst_marshal_BOOLEAN__POINTER (gstmarshal.c:584)
==25840==    by 0xC2B1FA: g_closure_invoke (gclosure.c:767)
==25840==    by 0xC41654: signal_emit_unlocked_R (gsignal.c:3244)
==25840==    by 0x6F50884: gst_pad_emit_have_data_signal (gstpad.c:3817)
==25840==    by 0x6F54749: gst_pad_chain_unchecked (gstpad.c:3855)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x62ECC67: gst_selector_pad_chain (gststreamselector.c:424)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6F465B9: gst_proxy_pad_do_chain (gstghostpad.c:207)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6E6B9F4: (within /usr/lib/gstreamer-0.10/libgstmad.so)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6C8E7E0: (within /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so)
==25840==    by 0x6C902AF: (within /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x58F4CE9: gst_icydemux_typefind_or_forward (gsticydemux.c:479)
==25840==    by 0x58F518F: gst_icydemux_chain (gsticydemux.c:524)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x63138E9: gst_type_find_element_chain (gsttypefindelement.c:622)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6F465B9: gst_proxy_pad_do_chain (gstghostpad.c:207)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6350A30: gst_base_src_loop (gstbasesrc.c:2187)
==25840==    by 0x6F74D32: gst_task_func (gsttask.c:192)
==25840== 

==25840== 520,064 bytes in 2,032 blocks are possibly lost in loss record 237 of 244
==25840==    at 0x4006C0C: realloc (vg_replace_malloc.c:429)
==25840==    by 0x700909: g_realloc (gmem.c:170)
==25840==    by 0x6D11CF: g_array_maybe_expand (garray.c:339)
==25840==    by 0x6D1748: g_array_append_vals (garray.c:132)
==25840==    by 0x6F6B44C: gst_structure_set_field (gststructure.c:628)
==25840==    by 0x6F6C2CA: gst_structure_id_set_valist (gststructure.c:602)
==25840==    by 0x6F6C3BE: gst_structure_id_set (gststructure.c:560)
==25840==    by 0x6F4DB69: gst_message_new_buffering (gstmessage.c:471)
==25840==    by 0x62E92A0: check_queue (gstplaybasebin.c:524)
==25840==    by 0x6F8FD55: gst_marshal_BOOLEAN__POINTER (gstmarshal.c:584)
==25840==    by 0xC2B1FA: g_closure_invoke (gclosure.c:767)
==25840==    by 0xC41654: signal_emit_unlocked_R (gsignal.c:3244)
==25840==    by 0x6F50884: gst_pad_emit_have_data_signal (gstpad.c:3817)
==25840==    by 0x6F54749: gst_pad_chain_unchecked (gstpad.c:3855)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x62ECC67: gst_selector_pad_chain (gststreamselector.c:424)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6F465B9: gst_proxy_pad_do_chain (gstghostpad.c:207)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6E6B9F4: (within /usr/lib/gstreamer-0.10/libgstmad.so)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6C8E7E0: (within /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so)
==25840==    by 0x6C902AF: (within /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x58F4CE9: gst_icydemux_typefind_or_forward (gsticydemux.c:479)
==25840==    by 0x58F518F: gst_icydemux_chain (gsticydemux.c:524)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x63138E9: gst_type_find_element_chain (gsttypefindelement.c:622)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6F465B9: gst_proxy_pad_do_chain (gstghostpad.c:207)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6350A30: gst_base_src_loop (gstbasesrc.c:2187)
==25840==    by 0x6F74D32: gst_task_func (gsttask.c:192)
==25840== 

==25840== 268,705,730 (24,086,080 direct, 244,619,650 indirect) bytes in 756,575 blocks are definitely lost in loss record 242 of 244
==25840==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==25840==    by 0x700A23: g_malloc (gmem.c:131)
==25840==    by 0x717542: g_slice_alloc (gslice.c:824)
==25840==    by 0x717874: g_slice_alloc0 (gslice.c:833)
==25840==    by 0x6F6DC3A: gst_structure_id_empty_new_with_size (gststructure.c:116)
==25840==    by 0x6F4DAA1: gst_message_new_buffering (gstmessage.c:470)
==25840==    by 0x62E92A0: check_queue (gstplaybasebin.c:524)
==25840==    by 0x6F8FD55: gst_marshal_BOOLEAN__POINTER (gstmarshal.c:584)
==25840==    by 0xC2B1FA: g_closure_invoke (gclosure.c:767)
==25840==    by 0xC41654: signal_emit_unlocked_R (gsignal.c:3244)
==25840==    by 0x6F50884: gst_pad_emit_have_data_signal (gstpad.c:3817)
==25840==    by 0x6F54749: gst_pad_chain_unchecked (gstpad.c:3855)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x62ECC67: gst_selector_pad_chain (gststreamselector.c:424)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6F465B9: gst_proxy_pad_do_chain (gstghostpad.c:207)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6E6B9F4: (within /usr/lib/gstreamer-0.10/libgstmad.so)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6C8E7E0: (within /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so)
==25840==    by 0x6C902AF: (within /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x58F4CE9: gst_icydemux_typefind_or_forward (gsticydemux.c:479)
==25840==    by 0x58F518F: gst_icydemux_chain (gsticydemux.c:524)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x63138E9: gst_type_find_element_chain (gsttypefindelement.c:622)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6F465B9: gst_proxy_pad_do_chain (gstghostpad.c:207)
==25840==    by 0x6F547D8: gst_pad_chain_unchecked (gstpad.c:3877)
==25840==    by 0x6F55A19: gst_pad_push (gstpad.c:4045)
==25840==    by 0x6350A30: gst_base_src_loop (gstbasesrc.c:2187)
==25840==    by 0x6F74D32: gst_task_func (gsttask.c:192)
==25840==    by 0x724325: g_thread_pool_thread_proxy (gthreadpool.c:265)
==25840==    by 0x722C8E: g_thread_create_proxy (gthread.c:635)
Comment 1 Wim Taymans 2009-03-02 15:25:41 UTC
I can't really reproduce this here. totem seems to free the buffering messages fine.

What version of totem/gstreamer is this? are you unreffing the buffering messages received on the bus?

does it also happen with G_SLICE=always-malloc?


Comment 2 J.Rios 2009-03-02 17:21:49 UTC
Created attachment 129864 [details]
Valgrind totem log

created using command line G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log totem
Comment 3 J.Rios 2009-03-02 17:25:05 UTC
Im using Fedora core 10 with totem version is 2.24.3 and gstreamer0.10-21.2, but also tried in ubuntu 8.10 with same results.

Comment 4 Wim Taymans 2009-03-02 17:42:07 UTC
I don't see the leaked buffering messages in that log. I see some known leaks in GStreamer that are mainly because of cached things.

What in particular is disturbing you in that log?
Comment 5 J.Rios 2009-03-03 08:08:57 UTC
Thas log was takean for 3 mins of playing totem. And there is not the leaks shown in the first log but I cant play
a shoutcast stream with totem thought valgrind. I have not enought CPU power and it keeps buffering all the time.
I ran it without valgrind and did two captures the first once it started playing
the stream and the second after 6 hours running. See the difference in memory used by totem. Is that normal ?
Comment 6 J.Rios 2009-03-03 08:10:23 UTC
Created attachment 129924 [details]
Memoy used by totem when playing a shoutcast stream started
Comment 7 J.Rios 2009-03-03 08:11:13 UTC
Created attachment 129925 [details]
Memoy used by totem after 6 hours playing a shoutcast stream
Comment 8 Tim-Philipp Müller 2009-03-03 09:01:22 UTC
Does this also happen with gst-launch?

  gst-launch-0.10 playbin uri=http://....

What distro/versions of core/gst-plugins-base/gst-plugins-good/gst-plugins-ugly are you using?

Comment 9 J.Rios 2009-03-03 10:42:07 UTC
Im using fedora 10 and ubuntu 8.10

For example in ubuntu I have installed

# dpkg --list | grep gstreamer0.10
gstreamer0.10-alsa-0.10.21-3
gstreamer0.10-esd-0.10.10.4-1ubuntu1
gstreamer0.10-ffmpeg-0.10.5-1
gstreamer0.10-gnomevfs-0.10.21-3
gstreamer0.10-plugins-bad-0.10.8-1
gstreamer0.10-plugins-bad-multiverse-0.10.6-1ubuntu1               
gstreamer0.10-plugins-base-0.10.21-3
gstreamer0.10-plugins-base-apps-0.10.21-3
gstreamer0.10-plugins-good-0.10.10.4-1ubuntu1
gstreamer0.10-plugins-ugly-0.10.9-1ubuntu0.1
gstreamer0.10-plugins-ugly-multiverse-0.10.7-2
gstreamer0.10-pulseaudio-0.10.10.4-1ubuntu1
gstreamer0.10-schroedinger-1.0.5-1
gstreamer0.10-sdl-0.10.8-1
gstreamer0.10-tools-0.10.21-4
gstreamer0.10-x-0.10.21-3
libgstreamer0.10.0.0-0.10.21-4
libgstreamer0.10-dev-0.10.21-4

With gst-launch starts with 13.9Mb of used memory and after 1 hour it uses 18.7Mb. Is this memory usage normal ?


Comment 10 Tim-Philipp Müller 2009-03-05 22:47:51 UTC
I can sort of reproduce this on my system with gst-launch, memory usage in system-monitor increases slowly but steadily. Can't spot anything obvious with valgrind though, need to take a closer look.

   souphttpsrc ! typefind ! mp3parse ! fakesink

seems to exhibit the problem as well.
Comment 11 Michael Smith 2009-03-05 22:55:37 UTC
Is this just mp3parse building its accurate seeking table? That'll increase over time but not actually leak.

Hrm... not obvious what the fix would be for that.
Comment 12 Michael Smith 2009-04-20 19:23:14 UTC
Will fix this by not building the seek table if we can't seek (as determined by a seeking query).
Comment 13 Michael Smith 2009-04-20 20:27:41 UTC
Created attachment 132987 [details] [review]
Don't build the seektable if it's not seekable
Comment 14 Michael Smith 2009-04-21 21:20:44 UTC
Committed as: e7450c2df7d5adf67c7327bf254e43839377f0c1
Comment 15 Paul Fleischer 2009-08-05 21:03:40 UTC
When using the souphttpsrc directly, the problem seems to persist even with the fix. For instance, using this the following pipeline with an mp3 shoutcast station will still build the seektable:

gst-launch souphttpsrc location="" ! mp3parser ! fakesink

How about adding a property to mp3parse which allows one to disable the seektable explicitly?

FYI, I'm using Ubuntu Jaunty with the gstreamer-developer PPA. The packages have the following versions:
gstreamer0.10-alsa      0.10.23.3-1~bpo1
gstreamer0.10-ffmpeg    0.10.7-1~bpo40+1
gstreamer0.10-plugins-bad       0.10.13-1~jaunty1
gstreamer0.10-plugins-bad-multiverse    0.10.11-0ubuntu1
gstreamer0.10-plugins-base      0.10.23.3-1~bpo1
gstreamer0.10-plugins-base-apps 0.10.23.3-1~bpo1
gstreamer0.10-plugins-base-dbg  0.10.23.3-1~bpo1
gstreamer0.10-plugins-base-doc  0.10.24-1~jaunty1
gstreamer0.10-plugins-good      0.10.15-1~bpo40+1
gstreamer0.10-plugins-ugly      0.10.12-1~jaunty1
gstreamer0.10-pulseaudio        0.10.15-1~bpo40+1
gstreamer0.10-schroedinger      1.0.5-1
gstreamer0.10-tools     0.10.24-1~jaunty1
gstreamer0.10-x 0.10.23.3-1~bpo1
libgstreamer-plugins-base0.10-0 0.10.23.3-1~bpo1
libgstreamer-plugins-base0.10-dev       0.10.23.3-1~bpo1
libgstreamer0.10-0      0.10.24-1~jaunty1
libgstreamer0.10-dev    0.10.24-1~jaunty1