[gst-devel] A hang inside gst_task_join()

[Loc Nguyen]

On 6/6/2010 10:17 PM, gstreamer-devel-request at lists.sourceforge.net wrote:
> When the queue is asked to do a state change to READY, it first sets its
> state to flushing and then it signals the item_add cond variable (see
> gst_queue_src_activate_push(). This makes the task go into paused where
> the core does a join on it.
>   
Wim,

Not knowing the full tear down sequence, I'm trying to fill in the holes 
here.  Our original sequence was to set the pipeline state to null then 
unref it.  From what you're saying, the queue is changing state to 
READY.  I assume this is during setting the pipeline state to null and 
NOT during unref'ing.  Am I reading this correctly in your explanation?  
During this operation to set the pipeline state to null, the pads are 
activated again (interesting)?  This causes the queue to signal and 
flush, exiting the task function.

Then by the time we unref the pipeline, the task function is no longer 
waiting on the queue, and the join succeeds.  Is this correct?  If I am 
understanding this correctly, then the problem is why are we still 
waiting in the gst_queue_loop().  I am sure it's the same task -- same 
function pointer address.  We've come up with a theory (assuming my 
interpretation of your explanation is correct) on why this is 
happening.  Here goes.

We followed an example from the gstreamer manual that showed setting the 
pipeline's state to null then immediately unref the pipeline.  The 
theory is that the pipeline hasn't reached null yet by the time we go to 
unref the pipeline.  During unref, we finalize the pad and try to join 
the task.  This occurs before the set to null state had a chance to 
activate the pad again, which would cause the wait in the queue loop to 
signal and exit.  Since the pad got finalized, it no longer receives 
events, including the activate event.  So the task is waiting, but the 
pad no longer accepts the event telling it to activate.  Thus, the 
hang.  Sound reasonable?

We're theorizing that after setting the pipeline's state to null, we 
should not immediately unref it.  Instead, we should wait for the state 
change then unref it.  What do you think?

Since sending out this first request, we've seen this hang on several 
more machines.

-Loc