[gst-devel] A hang inside gst_task_join()
loc.x.nguyen at oracle.com
Tue Jun 8 00:49:54 CEST 2010
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.
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 information about the gstreamer-devel