[Webkit-unassigned] [Bug 170003] [GStreamer] Deadlock in MediaPlayerPrivateGStreamer::changePipelineState, web process often locks up on seeking in a youtube video that has already fully buffered

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=170003

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cgarcia at igalia.com

--- Comment #10 from Carlos Garcia Campos <cgarcia at igalia.com> ---
I can't reproduce it either, but I think I know what's going on.

 - Thread 41. Takes preroll mutex in gst_base_sink_chain_main before calling ::render. In WebKit code, the render schedules a repaint in the main thread, and keeps waiting on draw mutex.

 - Main thread. pause() is requested causing the state change from PLAYING to PAUSE. That ends up changing the state of the video sink to in gst_base_sink_change_state(). It tries to take the preroll lock too, but Thread 41 hasn't released it yet, and it's waiting for us to do the repaint.

GStreamer actually handles this case, by calling ::unlock on the sink before trying to take the preroll lock. The problem is that WebKit is not canceling the draw timer and release the draw mutes in that case. The code path not using coordinated graphics does that indeed with its paint timer and mutex.

I'll prepare a patch, but I can't reproduce it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170605/4f60deea/attachment.html>