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 514965 - Possible buffer leaks if last_write_result != GST_FLOW_OK in gst_ebml_write_element_push
Possible buffer leaks if last_write_result != GST_FLOW_OK in gst_ebml_write_e...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal critical
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-07 12:51 UTC by Bjarne Rosengren
Modified: 2008-02-07 16:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bjarne Rosengren 2008-02-07 12:51:57 UTC
Please describe the problem:
(I'm new to gstreamer so I might have misunderstood some of this...) 
A GstBuffer will leak in gst_ebml_write_element_push () in ebml-write.c  if the last gst_pad_push () call did not result in a GST_FLOW_OK. This is since the GstBuffer is supposed to be unref'ed by gst_pad_push ().

A quick fix is the patch below but I'm not sure it is the best way of doing it since it will only hide the problem...
diff -u -r1.1.1.2 ebml-write.c
--- gst-plugins-good/gst-plugins-good/gst/matroska/ebml-write.c  23 Aug 2006 16:11:26 -0000      1.1.1.2
+++ gst-plugins-good/gst-plugins-good/gst/matroska/ebml-write.c  7 Feb 2008 12:43:50 -0000
@@ -371,6 +371,8 @@
     buf = gst_buffer_make_metadata_writable (buf);
     gst_buffer_set_caps (buf, GST_PAD_CAPS (ebml->srcpad));
     ebml->last_write_result = gst_pad_push (ebml->srcpad, buf);
+  } else {
+    gst_buffer_unref (buf);
   }
 }


Steps to reproduce:
I found this after running a perhaps buggy pipeline that resulted in two eof sent to the matroskamux. 
If I read the code correctly it might also be visible if a file error occurs will gst_matroska_mux_finish is running, there is _no_ error checks in this function at all...
I'm sorry to no have a more specific way of reproducing it.

Actual results:


Expected results:


Does this happen every time?


Other information:
Part of output from Valgrind:
==14820== 49,900 (39,920 direct, 9,980 indirect) bytes in 499 blocks are definitely lost in loss record 3,793 of 3,794
==14820==    at 0x401D38B: malloc (vg_replace_malloc.c:149)
==14820==    by 0x43778E5: g_malloc (in /home/bjarne/haiti/p1621_test/target/host/usr/lib/libglib-2.0.so.0.1400.5)
==14820==    by 0x438C722: g_slice_alloc (in /home/bjarne/haiti/p1621_test/target/host/usr/lib/libglib-2.0.so.0.1400.5)
==14820==    by 0x438CE04: g_slice_alloc0 (in /home/bjarne/haiti/p1621_test/target/host/usr/lib/libglib-2.0.so.0.1400.5)
==14820==    by 0x433224B: g_type_create_instance (in /home/bjarne/haiti/p1621_test/target/host/usr/lib/libgobject-2.0.so.0.1400.5)
==14820==    by 0x419F9A5: gst_mini_object_new (gstminiobject.c:162)
==14820==    by 0x414DF35: gst_buffer_new (gstbuffer.c:291)
==14820==    by 0x414E030: gst_buffer_new_and_alloc (gstbuffer.c:320)
==14820==    by 0x68F2332: gst_ebml_write_element_new (ebml-write.c:234)
==14820==    by 0x68F2BC4: gst_ebml_write_uint (ebml-write.c:475)
==14820==    by 0x6904A7A: gst_matroska_mux_finish (matroska-mux.c:1535)
==14820==    by 0x69065A2: gst_matroska_mux_collected (matroska-mux.c:1938)
==14820==    by 0x4063090: gst_collect_pads_check_collected (gstcollectpads.c:954)
==14820==    by 0x4063AC3: gst_collect_pads_event (gstcollectpads.c:1054)
==14820==    by 0x6901084: gst_matroska_mux_handle_sink_event (matroska-mux.c:497)
==14820==    by 0x41BCA33: gst_pad_send_event (gstpad.c:4256)
==14820==    by 0x41BB9E6: gst_pad_push_event (gstpad.c:4112)
==14820==    by 0x4058601: gst_base_transform_sink_event (gstbasetransform.c:1236)
==14820==    by 0x41BCA33: gst_pad_send_event (gstpad.c:4256)
==14820==    by 0x41BB9E6: gst_pad_push_event (gstpad.c:4112)
==14820==    by 0x418681A: gst_proxy_pad_do_event (gstghostpad.c:140)
==14820==    by 0x41BCA33: gst_pad_send_event (gstpad.c:4256)
==14820==    by 0x41BB9E6: gst_pad_push_event (gstpad.c:4112)
==14820==    by 0x404E1F8: gst_base_src_loop (gstbasesrc.c:2091)
==14820==    by 0x41F86B6: gst_task_func (gsttask.c:192)
==14820==    by 0x43952D6: (within /home/bjarne/haiti/p1621_test/target/host/usr/lib/libglib-2.0.so.0.1400.5)
==14820==    by 0x439374E: (within /home/bjarne/haiti/p1621_test/target/host/usr/lib/libglib-2.0.so.0.1400.5)
==14820==    by 0x440423F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so)
==14820==    by 0x44DC4AD: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
Comment 1 Sebastian Dröge (slomo) 2008-02-07 16:39:54 UTC
Not exactly a critical bug IMHO but still a bug :) Thanks for reporting, the fix is committed to CVS now with a small change (we don't unref the buffer if it's the one from the cache):

2008-02-07  Sebastian Dröge  <slomo@circular-chaos.org>

        Patch by: Bjarne Rosengren <bjarne at axis dot com>

        * gst/matroska/ebml-write.c: (gst_ebml_write_element_push):
        Don't leak buffers when we don't push them downstream.
        Fixes bug #514965.