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 730167 - panic in gst_bin_continue_func() when doing continuous zap operations
panic in gst_bin_continue_func() when doing continuous zap operations
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.36
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-15 05:22 UTC by bcxa.sz
Modified: 2014-05-15 10:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bcxa.sz 2014-05-15 05:22:26 UTC
The panic is like below:

Program terminated with signal 11, Segmentation fault.
  • #0 g_static_rec_mutex_get_rec_mutex_impl
    at ../../glib/deprecated/gthread-deprecated.c line 676
  • #0 g_static_rec_mutex_get_rec_mutex_impl
    at ../../glib/deprecated/gthread-deprecated.c line 676
  • #1 g_static_rec_mutex_lock
    at ../../glib/deprecated/gthread-deprecated.c line 711
  • #2 gst_bin_continue_func
    at gstbin.c line 2741
  • #3 g_thread_pool_thread_proxy
    at ../../glib/gthreadpool.c line 309
  • #4 g_thread_proxy
    at ../../glib/gthread.c line 797
  • #5 start_thread
    at pthread_create.c line 299
  • #6 clone
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S line 100
  • #7 clone
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S line 100
  • #2 gst_bin_continue_func
    at gstbin.c line 2741
$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.
Comment 1 bcxa.sz 2014-05-15 05:27:06 UTC
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)
Comment 2 bcxa.sz 2014-05-15 05:28:41 UTC
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?
Comment 3 Sebastian Dröge (slomo) 2014-05-15 06:53:33 UTC
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.
Comment 4 bcxa.sz 2014-05-15 10:09:02 UTC
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?
Comment 5 Tim-Philipp Müller 2014-05-15 10:26:22 UTC
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.