GNOME Bugzilla – Bug 775893
decodbin: Leaking pads on errors
Last modified: 2017-01-18 11:10:33 UTC
Created attachment 341685 [details] xz-compressed full asan error This file: http://samples.mplayerhq.hu/V-codecs/ACDV/hd-laser02.avi causes many memory leaks with G_SLICE=always-malloc. The full asan trace is too long, I'll attach it. The first error: ==20436==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 1312 byte(s) in 2 object(s) allocated from: #0 0x4d4e38 in malloc (/usr/bin/gst-discoverer-1.0+0x4d4e38) #1 0x7fb3805f6c98 in g_malloc /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmem.c:94 #2 0x7fb38060ed7f in g_slice_alloc /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gslice.c:1025 #3 0x7fb38060f34d in g_slice_alloc0 /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gslice.c:1051 #4 0x7fb3808ed671 in g_type_create_instance /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gtype.c:1848 #5 0x7fb3808d0546 in g_object_new_internal /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gobject.c:1783 #6 0x7fb3808d2384 in g_object_new_valist /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gobject.c:2042 #7 0x7fb3808d26c0 in g_object_new /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gobject.c:1626 #8 0x7fb375ed64dd in gst_decode_pad_new /f/gstreamer/gst-plugins-base/gst/playback/gstdecodebin2.c:5086:7 #9 0x7fb375ed64dd in analyze_new_pad /f/gstreamer/gst-plugins-base/gst/playback/gstdecodebin2.c:1567 #10 0x7fb375eee450 in pad_added_cb /f/gstreamer/gst-plugins-base/gst/playback/gstdecodebin2.c:2929:7 #11 0x7fb37f8db01f in ffi_call_unix64 (/usr/lib64/libffi.so.6+0x601f) #12 0x7fb37f8daa87 in ffi_call (/usr/lib64/libffi.so.6+0x5a87) #13 0x7fb3808cb7e3 in g_cclosure_marshal_generic /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gclosure.c:1490 #14 0x7fb3808cafd4 in g_closure_invoke /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gclosure.c:804 #15 0x7fb3808dd360 in signal_emit_unlocked_R /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gsignal.c:3635 #16 0x7fb3808e5e08 in g_signal_emit_valist /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gsignal.c:3391 #17 0x7fb3808e606e in g_signal_emit /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/gobject/gsignal.c:3447 #18 0x7fb3812d582b in gst_element_add_pad /f/gstreamer/gstreamer/gst/gstelement.c:713:3 #19 0x7fb374200528 in gst_avi_demux_expose_streams /f/gstreamer/gst-plugins-good/gst/avi/gstavidemux.c:1882:7 #20 0x7fb3741ee8cf in gst_avi_demux_stream_header_pull /f/gstreamer/gst-plugins-good/gst/avi/gstavidemux.c:4307:3 #21 0x7fb3741e2746 in gst_avi_demux_loop /f/gstreamer/gst-plugins-good/gst/avi/gstavidemux.c:5672:13 #22 0x7fb38141ba03 in gst_task_func /f/gstreamer/gstreamer/gst/gsttask.c:334:5 #23 0x7fb380619857 in g_thread_pool_thread_proxy /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gthreadpool.c:307 #24 0x7fb380618ec4 in g_thread_proxy /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gthread.c:784 #25 0x7fb380095453 in start_thread (/lib64/libpthread.so.0+0x7453) #26 0x7fb37fbc55dc in clone (/lib64/libc.so.6+0xe75dc)
Confirmed here, also with valgrind. Looks like half of decodebin is leaking here
I think we're only leaking a reference to a GstDecodePad here (which then pulls in all the other leaks indirectly), in this specific error path. I couldn't find the place where though
Created attachment 343691 [details] [review] decodebin: Don't leak blocked pad references on errors When the decodebin state change fails because of an error message, we might not go through PAUSED->READY. Don't leak a ref to decodebin pads due to pad blocking in that case. This is because we return ASYNC going to PAUSED, and if we fail before reaching PAUSED the only transition we'll see is READY->NULL.
commit 54bf10427402c9ac046ea694e6b48d3d976d55e1 Author: Jan Schmidt <jan@centricular.com> Date: Wed Jan 18 14:59:18 2017 +1100 decodebin: Don't leak blocked pad references on errors When the decodebin state change fails because of an error message, we might not go through PAUSED->READY. Don't leak a ref to decodebin pads due to pad blocking in that case. This is because we return ASYNC going to PAUSED, and if we fail before reaching PAUSED the only transition we'll see is READY->NULL. https://bugzilla.gnome.org/show_bug.cgi?id=775893