[Bug 690420] Random lock-up in GstDiscoverer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=690420
  GStreamer | gst-plugins-base | 1.x

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #6 from Wim Taymans <wim.taymans at gmail.com> 2012-12-21 15:08:10 UTC ---
Thread 1 and 3 are important. Thread 5,4,2 are from a previous run.

Thread 1 is doing the state change on the decodebin and has just managed to set
the state on typefind.

Thread 3 has just finished the typefind and is signaling the type-found signal.
Decodebin then added the flacparse element.

Thread 1 sees that a new element flacparse3 is added to the pipeline and
restarts the state change, it now tries to set the state of the new flacparse
to PAUSED. 

Thread 3 tries to set the flacparse to READY but blocks on the state lock
because
thread 1 was first.

In thread 1: The flacparse tries to activate the peer pad in pull mode and for
that it needs to deactivate the stream thread first, this deadlocks because
thread 3 holds the stream lock and is blocked in the state-lock.

It sounds like we need to prevent the bin from doing the resync and changing
the state for us.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.