mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-31 03:29:50 +00:00
9036dc8594
There was a deadlock between a thread changing decodebin/demuxer state from PAUSED to READY, and another thread pushing data when starting. From the stack trace at https://bug741355.bugzilla-attachments.gnome.org/attachment.cgi?id=292471, I deduce the following is happening, though I did not reproduce the problem so I'm not sure this patch fixes it. The streaming thread (thread 2 in that stack trace) takes the demuxer's sink pad's stream lock in gst_ogg_demux_perform_seek_pull and will activate a new chain. This ends up causing the expose lock being taken in _pad_added_cb in decodebin. Meanwhile, a state changed is triggered on thread 1, which takes the expose lock in decodebin in gst_decode_bin_change_state, then frees the previous chain, which ends up calling gst_pad_stop_task on the demuxer's task, which in turn takes the demuxer's sink pad's stream lock, deadlocking as both threads are now waiting for each other. https://bugzilla.gnome.org/show_bug.cgi?id=741355 |
||
|---|---|---|
| .. | ||
| adder | ||
| app | ||
| audioconvert | ||
| audiorate | ||
| audioresample | ||
| audiotestsrc | ||
| encoding | ||
| gio | ||
| playback | ||
| subparse | ||
| tcp | ||
| typefind | ||
| videoconvert | ||
| videorate | ||
| videoscale | ||
| videotestsrc | ||
| volume | ||
| Makefile.am | ||