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 741993 - souphttpsrc: leaking a buffer during flushing
souphttpsrc: leaking a buffer during flushing
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-12-26 11:18 UTC by Nicola
Modified: 2014-12-30 15:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicola 2014-12-26 11:18:31 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
Comment 1 Thiago Sousa Santos 2014-12-30 12:36:28 UTC
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.
Comment 2 Nicola 2014-12-30 12:55:45 UTC
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)
Comment 3 Nicola 2014-12-30 13:19:39 UTC
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
Comment 4 Sebastian Dröge (slomo) 2014-12-30 15:27:23 UTC
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
Comment 5 Nicola 2014-12-30 15:34:41 UTC
I confirm that the above commit fix the leak, thanks!