GNOME Bugzilla – Bug 741993
souphttpsrc: leaking a buffer during flushing
Last modified: 2014-12-30 15:46:07 UTC
sometime I get this memleak from valgrind: ==5329== 4,519 (272 direct, 4,247 indirect) bytes in 1 blocks are definitely lost in loss record 4,352 of 4,376 ==5329== at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5329== by 0x58F8579: g_malloc (in /usr/lib/libglib-2.0.so.0.4200.1) ==5329== by 0x590F3DF: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.4200.1) ==5329== by 0x4E6CB0A: gst_buffer_new (gstbuffer.c:632) ==5329== by 0x4E6DA82: gst_buffer_new_allocate (gstbuffer.c:680) ==5329== by 0x8E86D34: gst_base_src_default_alloc (gstbasesrc.c:1435) ==5329== by 0x88013CD: gst_soup_http_src_chunk_allocator (gstsouphttpsrc.c:1356) ==5329== by 0x911F0CA: ??? (in /usr/lib/libsoup-2.4.so.1.7.0) ==5329== by 0x911F542: ??? (in /usr/lib/libsoup-2.4.so.1.7.0) ==5329== by 0x91200F4: ??? (in /usr/lib/libsoup-2.4.so.1.7.0) ==5329== by 0x912034A: ??? (in /usr/lib/libsoup-2.4.so.1.7.0) ==5329== by 0x58F291C: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.4200.1) ==5329== by 0x58F2CF7: ??? (in /usr/lib/libglib-2.0.so.0.4200.1) ==5329== by 0x58F3021: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.4200.1) ==5329== by 0x8803D7B: gst_soup_http_src_do_request (gstsouphttpsrc.c:1686) ==5329== by 0x8804868: gst_soup_http_src_create (gstsouphttpsrc.c:1726) ==5329== by 0x8E88D79: gst_base_src_get_range (gstbasesrc.c:2455) ==5329== by 0x8E8AC62: gst_base_src_loop (gstbasesrc.c:2731) ==5329== by 0x4ECBF70: gst_task_func (gsttask.c:316) ==5329== by 0x5919F87: ??? (in /usr/lib/libglib-2.0.so.0.4200.1) using this pipeline: souphttpsrc location=... do-timestamp=true is-live=true ! jpegparse ! jpegdec ! queue ! openh264enc rate-control=1 enable-frame-skip=1 bitrate=1024000 ! fakesink silent=false it does not happen always, probably some corner case in gstreamer or libsoup I'm using git master with libsoup 2.48.1
Did you try running a simpler pipeline to see if the leak still happens? Removing the h264 encoder part, and then the jpeg to see if the leak is still present without those elements? This could help pinpoint which one might be leaking.
This leak does not happen every time, i did some more tests: 1) original pipeline I observed the leak 1 time in 5 run 2) without openh264enc 1 time in 5 run 3) without jpegdec 1 time in 5 run (only souphttpsrc ! queue ! fakesink) so the leak seems in souphttpsrc, could be some corner case in souphttpsrc element or in libsoup itself (I'm using a newer version not yet used in cerbero)
If I try with a camera with a low framerate or if I add num-buffers=xxxx to souphttpsrc I'm unable to reproduce the leak, so seems something happen if I stop the pipeline while it is processing a frame
This might be fixed by this commit, please test :) commit bbcfc3b9e632f490880a68397078bf1b998d499d Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Dec 30 16:26:58 2014 +0100 souphttpsrc: Don't return a buffer when returning not GST_FLOW_OK basesrc assumes that we don't return a buffer if something else than OK is returned. It will just leak any buffer we might accidentially provide here. This can potentially happen during flushing. Maybe fixes https://bugzilla.gnome.org/show_bug.cgi?id=741993
I confirm that the above commit fix the leak, thanks!