[Bug 787144] Memory leak in gstqtmux.c

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=787144

--- Comment #5 from Anton Nikolaevsky <anton.nikolaevsky at gmail.com> ---
Please, ignore my previous statement regarding the data race I thought I'd
found. Today I had time to investigate the problem more carefully.
Unfortunately, I haven't kept original crash report so now I'm not sure whether
I indeed saw gst_buffer_unref in the crash stack (I was in a little bit of
hurry reporting the patch can lead to crash). All stacks I've collected today
were triggered by gst_debug_print_object at gstreamer-1.11.2/gst/gstinfo.c:885
(i.e. by tracing routines, not the gst_buffer_unref call) and the guilty object
turned out to be qtpad (not the leaking fragment buffer as I thought
previously).

#0  0x00007ffff56e0067 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff56e1448 in __GI_abort () at abort.c:89
#2  0x00007ffff6f66f29 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.1
#3  0x00007ffff6f5eca5 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.1
#4  0x00007ffff6f62aa2 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.1
#5  0x00007ffff6f5e139 in __asan_report_error () from
/usr/lib/x86_64-linux-gnu/libasan.so.1
#6  0x00007ffff6f5f014 in __asan_report_load8 () from
/usr/lib/x86_64-linux-gnu/libasan.so.1
#7  0x00007ffff67a6b4c in g_type_check_instance_is_fundamentally_a
(type_instance=type_instance at entry=0x61400000bc40,
fundamental_type=fundamental_type at entry=80) at gtype.c:3982
#8  0x00007ffff6b10c2f in gst_debug_print_object (ptr=ptr at entry=0x61400000bc40)
at gstinfo.c:885
#9  0x00007ffff6b139b7 in gst_debug_log_default (category=0x603000434c80,
level=GST_LEVEL_TRACE, file=0x7fffec837fc0 "gstqtmux.c", function=<optimized
out>, line=<optimized out>, object=<optimized out>, message=0x7fffffffda40, 
    user_data=0x7ffff5a51060 <_IO_2_1_stderr_>) at gstinfo.c:1159
#10 0x00007ffff6b12f08 in gst_debug_log_valist
(category=category at entry=0x603000434c80, level=level at entry=GST_LEVEL_TRACE,
file=<optimized out>, function=<optimized out>, line=<optimized out>,
object=<optimized out>, 
    format=0x7fffec839600 " dropping fragment buffer %s", args=0x7fffffffdb30)
at gstinfo.c:566
#11 0x00007ffff6b1312e in gst_debug_log (category=0x603000434c80,
level=level at entry=GST_LEVEL_TRACE, file=file at entry=0x7fffec837fc0 "gstqtmux.c",
function=function at entry=0x7fffec83ef80 <__func__.27089> "gst_qt_mux_pad_reset", 
    line=line at entry=545, object=object at entry=0x61400000bc40,
format=0x7fffec839600 " dropping fragment buffer %s") at gstinfo.c:498
#12 0x00007fffec7dc6e2 in gst_qt_mux_pad_reset
(qtpad=qtpad at entry=0x61400000bc40) at gstqtmux.c:545
#13 0x00007fffec7dcdf0 in gst_qt_mux_reset (qtmux=qtmux at entry=0x616000006680,
alloc=alloc at entry=1) at gstqtmux.c:606
#14 0x00007fffec7ddbc7 in gst_qt_mux_change_state (element=0x616000006680,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstqtmux.c:5048
#15 0x00007ffff6aff9b2 in gst_element_change_state
(element=element at entry=0x616000006680,
transition=transition at entry=GST_STATE_CHANGE_PAUSED_TO_READY) at
gstelement.c:2743
#16 0x00007ffff6b009c5 in gst_element_set_state_func (element=0x616000006680,
state=GST_STATE_READY) at gstelement.c:2697
#17 0x00007ffff6abadbe in gst_bin_element_set_state (next=GST_STATE_READY,
current=GST_STATE_PAUSED, start_time=0, base_time=3559671532276824,
element=0x616000006680, bin=0x6150000082c0) at gstbin.c:2589
#18 gst_bin_change_state_func (element=0x6150000082c0, transition=<optimized
out>) at gstbin.c:2931
#19 0x00007ffff6aff9b2 in gst_element_change_state
(element=element at entry=0x6150000082c0,
transition=transition at entry=GST_STATE_CHANGE_PAUSED_TO_READY) at
gstelement.c:2743
#20 0x00007ffff6b009c5 in gst_element_set_state_func (element=0x6150000082c0,
state=GST_STATE_READY) at gstelement.c:2697
#21 0x000000000040457c in main (argc=17, argv=0x7fffffffe6d8) at
gst-launch.c:1216

... and nothing data race alike in different threads.

To be sure I've replaced GST_TRACE_OBJECT with GST_TRACE and got rid of qtpad
reference and gst-launch has ceased to crash.
As for the crashing on accessing qtpad object I did not investigate further
whether it is expected behavior at this point of a pipeline destruction. I
suppose it might be so.

CONCLUSION: the patch I originally proposed should be rejected, without tracing
line it must be safe enough - this is exactly what Matej posted at
https://bugzilla.gnome.org/attachment.cgi?id=359046

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.