[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

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |slomo at circular-chaos.org
         Resolution|FIXED                       |

--- Comment #9 from Sebastian Dröge <slomo at circular-chaos.org> 2013-05-23 20:51:18 UTC ---
As Xabier found in bug #699124 this is introducing a fancy new bug caused by
GstBin *not* resyncing anymore and handling the element states for us. Which is
also part of bug #700342 and potentially others I had on my list since some
days.

What happens here is that we're still autoplugging in decodebin, but a state
change back from PAUSED to READY happens.

Thread 1 is currently inside decodebin's autoplugging code (which is called
from the streaming threads of the elements) and currently adding e.g. a parser
as a result of typefind's have-type signal.
Thread 2 at this time is inside GstBin's loop to change the decodebin children
from PAUSED to READY but does not know about the parser yet. It will block when
shutting down typefind, because thread 1 currently holds the stream lock of
typefind.

Thread 1 adds the parser, sets it to READY and PAUSED (and starts the thread 3
of the parser that pulls data from upstream) and let's the autoplugging
continue.
Thread 2 unblocks at some point because thread 1 does not hold the stream lock
anymore, and stops typefind.

Thread 3 continues autoplugging. thread 2 returns from the GstBin state change
function to the GstDecodeBin state change function, which now assumes that all
data flow has stopped. And now interested deadlocks and crashes are happening
everywhere because of broken assumptions everywhere.

For example: Thread 3 holding the stream lock of the parser is in the decodebin
autoplugging functions and wants to take decodebin's chain mutex. Thread 2 is
freeing all chains and holding the chain mutex (thus thread 3 can't take it),
and while holding it is setting the parsers state from PAUSED to READY, thus
trying to get the stream lock of the parser. Deadlock.


I'm not sure yet where all the crashes come from, there are also other bugs
involved not caused by this here but e.g. by bug #700806 (sticky events getting
dropped from pads before they're stored because of flushes and never resent) or
bug #688824 (sticky events getting dropped from queues before they're stored on
the srcpads of the queue and never resend... and serialized queries are never
answered) or bug #700006 (audio/video codec base classes returning NULL from
the allocate_buffer() function when flushing). Basically there seems to be a
whole bunch of loosely interconnected bugs that now include this one here too
:)

-- 
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.