[gst-devel] Crash when bringing up/down pipeline

[Crane, Matt]

I have a  video recording gstreamer application that is crashing,
apparently inside of a gstreamer pool thread, when trying to change
state from PAUSED to PLAYING.  The backtrace is as follows:  

 

#0  0xb78e4424 in ?? ()

#1  0xb41fe560 in ?? ()

#2  0x00000006 in ?? ()

#3  0x003cde28 in abort ()

   from libc.so.6

#4  0xb723e82f in IA__g_logv (

    log_domain=0xb71bb7a8 "\377t\031\215\263\350\376\377\377\215\264&",

    log_level=G_LOG_LEVEL_ERROR, format=0xb71bbaec "', previously locked
at '%s'",

    args1=0xb41feb2c "\260\267\033\267\266") at gmessages.c:549

#5  0xb723ebc6 in IA__g_log (

    log_domain=0xb71bb7a8 "\377t\031\215\263\350\376\377\377\215\264&",

    log_level=G_LOG_LEVEL_ERROR, format=0xb71bbaec "', previously locked
at '%s'")

    at gmessages.c:569

#6  0xb71bb1e4 in g_mutex_free_posix_impl (mutex=0xb6634c50) at
gthread-posix.c:181

#7  0xb5d610ea in gst_queue_finalize (object=0xb66ec8f0) at
gstqueue.c:421

#8  0xb71ca5a3 in IA__g_object_unref (_object=0xb66ec8f0) at
gobject.c:2411

#9  0xb707eb9f in gst_object_unref (object=0xb66ec8f0) at
gstobject.c:326

#10 0xb708639d in gst_bin_remove_func (bin=0xb47d31a0,
element=0xb66ec8f0) at gstbin.c:1391

#11 0xb7082d58 in gst_bin_remove (bin=0xb47d31a0, element=0xb66ec8f0) at
gstbin.c:1449

#12 0xb7089de6 in gst_bin_dispose (object=0xb47d31a0) at gstbin.c:535

#13 0xb71ca508 in IA__g_object_unref (_object=0xb47d31a0) at
gobject.c:2371

#14 0xb707eb9f in gst_object_unref (object=0xb47d31a0) at
gstobject.c:326

#15 0xb708639d in gst_bin_remove_func (bin=0x81e4330,
element=0xb47d31a0) at gstbin.c:1391

#16 0xb7082d58 in gst_bin_remove (bin=0x81e4330, element=0xb47d31a0) at
gstbin.c:1449

#17 0xb7089de6 in gst_bin_dispose (object=0x81e4330) at gstbin.c:535

#18 0xb71ca508 in IA__g_object_unref (_object=0x81e4330) at
gobject.c:2371

#19 0xb707eb9f in gst_object_unref (object=0x81e4330) at gstobject.c:326

#20 0xb7089640 in gst_bin_change_state_func (element=0x8266bf0,

    transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2453

#21 0xb709a418 in gst_element_change_state (element=0x8266bf0,

    transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstelement.c:2548

#22 0xb709db14 in gst_element_set_state_func (element=0x8266bf0,
state=GST_STATE_PLAYING)

    at gstelement.c:2504

#23 0xb7099620 in gst_element_set_state (element=0x8266bf0,
state=GST_STATE_PLAYING)

    at gstelement.c:2405

#24 0xb70893c7 in gst_bin_element_set_state (element=0xb66049a0,

    transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2118

#25 gst_bin_change_state_func (element=0xb66049a0,

    transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2417

#26 0xb70bf702 in gst_pipeline_change_state (element=0xb66049a0,

    transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstpipeline.c:467

#27 0xb709a418 in gst_element_change_state (element=0xb66049a0,

    transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstelement.c:2548

#28 0xb7083646 in gst_bin_continue_func (data=0x87da5c8) at
gstbin.c:2639

#29 0xb7260936 in g_thread_pool_thread_proxy (data=0x80f7248) at
gthreadpool.c:265

#30 0xb725f2cf in g_thread_create_proxy (data=0x87ef950) at
gthread.c:635

#31 0x0054f51f in start_thread ()

   from libpthread.so.0

#32 0x0048504e in clone ()

   from libc.so.6

 

At the time of this crash, the application was responding to a
GST_MESSAGE_ERROR from the GstBus while bringing up the pipeline.  The
error message was received after we were notified that we had reached
the PAUSED state but before we were notified that we had reached the
PLAYING state.  In response to a GST_MESSAGE_ERROR , our application
will tear down and bring the pipeline back up.  Tearing down the
pipeline involves setting the state of various bins in our pipeline to
the NULL state before calling gst_bin_remove().  We have determined that
there is a race condition between the application thread that reads
messages from the GstBus and the gstreamer pool thread identified above.
In the backtrace above, the pool thread is attempting change the state
of one of our bins to PLAYING at the same time our application thread is
removing the bin via gst_bin_remove.  The refcount of the bin goes to
zero in the above gstreamer pool thread and the pool thread then
attempts to dispose of the bin which eventually results in trying to
finalize a queue element in the bin and a failed attempt at trying to
free a locked queue mutex  which triggers a call to abort().

 

My questions:  Is there some special action we need to take when we
receive a GST_MESSAGE_ERROR before we tear down / bring up the pipeline
in cases where the GST_MESSAGE_ERROR is received before we are notified
that the pipeline has reached the PLAYING state?  In other words, is it
okay to tear down the pipeline in response to a GST_MESSAGE_ERROR before
it has reached the PLAYING state?  The gstreamer documentation indicates
"When the application receives an error message it should stop playback
of the pipeline and not assume that more data will be played."  But what
happens when we haven't been notified that playback has started?



Have we possibly come across a gstreamer bug that requires some
synchronization to be done internal to gstreamer?

 

Any info is greatly appreciated.

 

-Matt 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100707/15ec3ad1/attachment.htm>