[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

--- Comment #4 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-12-20 11:47:46 UTC ---
So I think this is a state-change / typefind issue. It looks like:

THREAD 5: flacparse ! flacdec ! queue ! ...
          queue waiting for ALLOCATION query to be handled by downstream
          waiting on WAIT_DEL_CHECK GCond in gst_queue_handle_sink_query()
          cur_level = { buffers = 0, bytes = 0, time = 0},
          max_size = {buffers = 1, bytes = 10485760, time = 1000000000},

THREAD 4: GstTask on typefind:sink pad
          has gone to PAUSED state
          waiting on GCond to resume

THREAD 3: another GstTask on typefind:sink pad ?!?
          in "have-type" emission from typefind loop function
          in decodebin's connect_pad
          setting flacparse element to READY state
          stuck in GST_STATE_LOCK (flacparse)

THREAD 2: GstBaseSink prerolled,
          stuck in wait_preroll waiting to go to PLAYING

THREAD 1: app/discoverer thread
          -> ASYNC_DONE message on bus
          -> discoverer_collect
          -> "discovered" signal
          -> old discoverer destroyed, new one set up and start_async
          -> new uridecodebin set to PAUSED state (after releasing disco lock)
          -> which will activate typefind pads, which will start a new pad task
             to do the typefinding from, and from which the 'have-type' signal
             is being emitted from as well
          -> at the end stuck in gst_base_parse_sink_activate (flacparse)


The big question for me is: how did thread 1 get to change state on flacparse?
Typefinding is not done in the application thread any more in 1.0, so if I'm
not mistaken what happens is basically that the pad task where the typefinding
occurs emits have-type, and decodebin then adds the flacparse element to the
bin, and proceeds to set it to READY/PAUSED state, BUT before it gets to that
the state change mechanism in the application thread from where we originally
started the typefinding picks up on the new element and tries to set its state
too, which then gets stuck doing stuff to the typefind pad task holding the
flacparse STATE lock, while the typefind pad task is stuck in decodebin waiting
for flacparse's STATE_LOCK to be released.

Any suggestions how to best fix this?

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