GNOME Bugzilla – Bug 730167
panic in gst_bin_continue_func() when doing continuous zap operations
Last modified: 2014-05-15 10:26:22 UTC
The panic is like below: Program terminated with signal 11, Segmentation fault.
+ Trace 233602
$1 = {bin = 0x2329380, cookie = 1, pending = GST_STATE_PLAYING} (gdb) print *(GstBin*)0x2329380 $2 = {element = {object = {object = {g_type_instance = {g_class = 0x2329268}, ref_count = 0, qdata = 0x0}, refcount = 0, lock = 0xde16540, name = 0x83aa470 "0\343M", name_prefix = 0x0, parent = 0x0, flags = 2, _gst_reserved = 0x0}, state_lock = 0x0, state_cond = 0x0, state_cookie = 2, current_state = GST_STATE_NULL, next_state = GST_STATE_VOID_PENDING, pending_state = GST_STATE_VOID_PENDING, last_return = GST_STATE_CHANGE_SUCCESS, bus = 0x0, clock = 0x0, base_time = 0, numpads = 0, pads = 0x0, numsrcpads = 0, srcpads = 0x0, numsinkpads = 0, sinkpads = 0x0, pads_cookie = 0, abidata = {ABI = { target_state = GST_STATE_NULL, start_time = 0}, _gst_reserved = {0x1, 0x0, 0x0, 0x0}}}, numchildren = 0, children = 0x0, children_cookie = 8, child_bus = 0x0, messages = 0x0, polling = 0, state_dirty = 0, clock_dirty = 0, provided_clock = 0x0, clock_provider = 0x0, priv = 0x2329468, _gst_reserved = {0x0, 0x0, 0x0}} (gdb) print *(GstObject*)0x2329380 $3 = {object = {g_type_instance = {g_class = 0x2329268}, ref_count = 0, qdata = 0x0}, refcount = 0, lock = 0xde16540, name = 0x83aa470 "0\343M", name_prefix = 0x0, parent = 0x0, flags = 2, _gst_reserved = 0x0} (gdb) print *(gchar*)0x83aa470 $4 = 48 '0' =================================================== Note: state_lock = 0x0 is definitely wrong which makes segmenation fault because after this lock will be accessed as point.
The use case is that: 1. create pipeline 2. change state from NULL to PLAYING 3. change state from PLAYING to NULL 4. unref the pipeline 5. back to 1 And in normal situtation, this gst_bin_continue_func() will be only called internally when async element commit state and this function will attempt to bring the bin to next state. And see below backtrace (which is correct): Breakpoint 1, gst_bin_continue_func (data=0x240f2060) at gstbin.c:2732 2732 in gstbin.c (gdb) print *(BinContinueData *)0x240f2060 $5 = {bin = 0x1ad0f3d8, cookie = 1, pending = GST_STATE_PLAYING} (gdb) print *(GstBin *)0x1ad0f3d8 $6 = {element = {object = {object = {g_type_instance = {g_class = 0x24034b70}, ref_count = 2, qdata = 0x0}, refcount = 0, lock = 0x240cc818, name = 0x231f180 "pipeline", name_prefix = 0x0, parent = 0x0, flags = 34, _gst_reserved = 0x0}, state_lock = 0xfdbcb40, state_cond = 0x240f6c20, state_cookie = 1, current_state = GST_STATE_PAUSED, next_state = GST_STATE_PLAYING, pending_state = GST_STATE_PLAYING, last_return = GST_STATE_CHANGE_ASYNC, bus = 0x24034370, clock = 0x1ad47aa0, base_time = 431913378946, numpads = 0, pads = 0x0, numsrcpads = 0, srcpads = 0x0, numsinkpads = 0, sinkpads = 0x0, pads_cookie = 0, abidata = {ABI = { target_state = GST_STATE_PLAYING, start_time = 0}, _gst_reserved = { 0x4, 0x0, 0x0, 0x0}}}, numchildren = 4, children = 0x240f3420, children_cookie = 4, child_bus = 0x240345f8, messages = 0x0, polling = 0, state_dirty = 0, clock_dirty = 0, provided_clock = 0x0, clock_provider = 0x0, priv = 0x1ad0f4c0, _gst_reserved = {0x0, 0x0, 0x0}} (gdb)
And why sometimes the panic happen, I thought: The pipeline has been changed from PLAYING to NULL and unref before the gst_bin_continue_func() want to commit the state from PAUSED to PLAYING. Look at gdb_backtrace.log: We can see ====================================================== current_state = GST_STATE_NULL, next_state = GST_STATE_VOID_PENDING, pending_state = GST_STATE_VOID_PENDING, last_return = GST_STATE_CHANGE_SUCCESS and many members are 0 and even name is '\0'. This piece of code can be found in gst_element_finalize() and gst_object_finalize(). ====================================================== And it maybe due to thread schedule, gst_bin_continue_func() is just called later than the operation to change pipeline from PLAYING to NULL then unref. Then it try to access the element which has been freed then segmentation happen. Do you think what I thought make sense? If yes, how to resolve such kind of issue?
GStreamer 0.10 is now longer maintained and supported, please reopen the bug if you can reproduce it with GStreamer 1.x. Also 0.10.34 was not the last 0.10 release, your bug might be fixed with 0.10.36, which was released about one year later.
Sorry, just realized that the gstreamer I installed is 0.10.36. ==================================================== root@b2120-h407_a9:~# gst-inspect playbin2 Factory Details: Long name: Player Bin 2 Class: Generic/Bin/Player Description: Autoplug and play media from an uri Author(s): Wim Taymans <wim.taymans@gmail.com> Rank: none (0) Plugin Details: Name: playback Description: various playback elements Filename: /usr/lib/gstreamer-0.10/libgstplaybin.so Version: 0.10.36 License: LGPL Source module: gst-plugins-base Source release date: 2012-02-20 Binary package: GStreamer Base Plug-ins source release Origin URL: Unknown package origin ====================================================== So I re-opened and let me know whether you can support 0.10.36 or have to move to 1.x??? Can you also check the description to see whether it can possible happen in 1.x?
0.10 is generally no longer maintained, please re-test with a recent 1.x version (1.2.x or 1.3.x). It's not easy to know whether this is still an issue with 1.x, some things have changed here.