[Bug 734688] gsttask: Deadlock when running gst_task_join()

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=734688
  GStreamer | gstreamer (core) | 1.2.4

--- Comment #12 from Linus Svensson <linus.svensson at axis.com> 2014-08-19 13:01:08 UTC ---
I'm getting different kind of deadlocks when reproducing this problem. As
mentioned before it's always the same element (queue between tee and appsink.
this is a pipeline in gst-rtsp-server when using tcp as transport) that causes
problems.

There always seem to be some problem with the task on the src pad of the queue.
In one case I actually had two tasks, both of them looked like the task on the
src pad. One task in state STOPPED and one task in state STARTED. The src pads
task pointer pointed to the STARTED task. It looked like the STOPPED task was
stopped from the rtsp server's client thread (currently running with only one
thread serving clients, even if it's possible to use more). The STOPPED task
was leaving state PAUSED and got stuck when it called g_rec_mutex_lock (lock)
on it's way out of the while loop in gst_task_func. This lock was held by the
STARTED task. The STARTED task waited for buffers in gst_queue_loop. I guess
that the bug is that the second task even got started in this case. 

I got the output from GST_DEBUG=queue:6,queue_dataflow:6,task:6,rtspclient:6
today. When TEARDOWN is beging served, the pipeline is set to GST_STATE_NULL,
but a deadlock occurs when finalizing the src pad of the queue (the queue is in
state NULL). The task on the pad is set to state STOPPED, but the task's thread
is executing gst_queue_loop (in NULL state). It looks like the streaming task
is stopped when doing the state transition PAUSED->READY, but a new task is
started. From the debug log I can see that gst_pad_start_task() when we
received a FLASH_STOP event.

I suspect that there might be a problem with this flush stop event. I don't
know why I see this event and where it comes from.

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