<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> 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:  <o:p></o:p> <o:p> </o:p> #0  0xb78e4424 in ?? ()<o:p></o:p> #1  0xb41fe560 in ?? ()<o:p></o:p> #2  0x00000006 in ?? ()<o:p></o:p> #3  0x003cde28 in abort ()<o:p></o:p>    from libc.so.6<o:p></o:p> #4  0xb723e82f in IA__g_logv (<o:p></o:p>     log_domain=0xb71bb7a8 "\377t\031\215\263\350\376\377\377\215\264&",<o:p></o:p>     log_level=G_LOG_LEVEL_ERROR, format=0xb71bbaec "', previously locked at '%s'",<o:p></o:p>     args1=0xb41feb2c "\260\267\033\267\266") at gmessages.c:549<o:p></o:p> #5  0xb723ebc6 in IA__g_log (<o:p></o:p>     log_domain=0xb71bb7a8 "\377t\031\215\263\350\376\377\377\215\264&",<o:p></o:p>     log_level=G_LOG_LEVEL_ERROR, format=0xb71bbaec "', previously locked at '%s'")<o:p></o:p>     at gmessages.c:569<o:p></o:p> #6  0xb71bb1e4 in g_mutex_free_posix_impl (mutex=0xb6634c50) at gthread-posix.c:181<o:p></o:p> #7  0xb5d610ea in gst_queue_finalize (object=0xb66ec8f0) at gstqueue.c:421<o:p></o:p> #8  0xb71ca5a3 in IA__g_object_unref (_object=0xb66ec8f0) at gobject.c:2411<o:p></o:p> #9  0xb707eb9f in gst_object_unref (object=0xb66ec8f0) at gstobject.c:326<o:p></o:p> #10 0xb708639d in gst_bin_remove_func (bin=0xb47d31a0, element=0xb66ec8f0) at gstbin.c:1391<o:p></o:p> #11 0xb7082d58 in gst_bin_remove (bin=0xb47d31a0, element=0xb66ec8f0) at gstbin.c:1449<o:p></o:p> #12 0xb7089de6 in gst_bin_dispose (object=0xb47d31a0) at gstbin.c:535<o:p></o:p> #13 0xb71ca508 in IA__g_object_unref (_object=0xb47d31a0) at gobject.c:2371<o:p></o:p> #14 0xb707eb9f in gst_object_unref (object=0xb47d31a0) at gstobject.c:326<o:p></o:p> #15 0xb708639d in gst_bin_remove_func (bin=0x81e4330, element=0xb47d31a0) at gstbin.c:1391<o:p></o:p> #16 0xb7082d58 in gst_bin_remove (bin=0x81e4330, element=0xb47d31a0) at gstbin.c:1449<o:p></o:p> #17 0xb7089de6 in gst_bin_dispose (object=0x81e4330) at gstbin.c:535<o:p></o:p> #18 0xb71ca508 in IA__g_object_unref (_object=0x81e4330) at gobject.c:2371<o:p></o:p> #19 0xb707eb9f in gst_object_unref (object=0x81e4330) at gstobject.c:326<o:p></o:p> #20 0xb7089640 in gst_bin_change_state_func (element=0x8266bf0,<o:p></o:p>     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2453<o:p></o:p> #21 0xb709a418 in gst_element_change_state (element=0x8266bf0,<o:p></o:p>     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstelement.c:2548<o:p></o:p> #22 0xb709db14 in gst_element_set_state_func (element=0x8266bf0, state=GST_STATE_PLAYING)<o:p></o:p>     at gstelement.c:2504<o:p></o:p> #23 0xb7099620 in gst_element_set_state (element=0x8266bf0, state=GST_STATE_PLAYING)<o:p></o:p>     at gstelement.c:2405<o:p></o:p> #24 0xb70893c7 in gst_bin_element_set_state (element=0xb66049a0,<o:p></o:p>     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2118<o:p></o:p> #25 gst_bin_change_state_func (element=0xb66049a0,<o:p></o:p>     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2417<o:p></o:p> #26 0xb70bf702 in gst_pipeline_change_state (element=0xb66049a0,<o:p></o:p>     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstpipeline.c:467<o:p></o:p> #27 0xb709a418 in gst_element_change_state (element=0xb66049a0,<o:p></o:p>     transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstelement.c:2548<o:p></o:p> #28 0xb7083646 in gst_bin_continue_func (data=0x87da5c8) at gstbin.c:2639<o:p></o:p> #29 0xb7260936 in g_thread_pool_thread_proxy (data=0x80f7248) at gthreadpool.c:265<o:p></o:p> #30 0xb725f2cf in g_thread_create_proxy (data=0x87ef950) at gthread.c:635<o:p></o:p> #31 0x0054f51f in start_thread ()<o:p></o:p>    from libpthread.so.0<o:p></o:p> #32 0x0048504e in clone ()<o:p></o:p>    from libc.so.6<o:p></o:p> <o:p> </o:p> 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().<o:p></o:p> <o:p> </o:p> 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? <o:p></o:p> Have we possibly come across a gstreamer bug that requires some synchronization to be done internal to gstreamer?<o:p></o:p> <o:p> </o:p> Any info is greatly appreciated.<o:p></o:p> <o:p> </o:p> -Matt <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>