[GTK] fast/canvas/canvas-createPattern-video-loading.html makes a following test timeout trunk@213127 > ./Tools/Scripts/run-webkit-tests --gtk --release --no-new-test-results -v fast/canvas/canvas-createPattern-video-loading.html fast/canvas/canvas-createPattern-video-modify.html > [1/2] fast/canvas/canvas-createPattern-video-loading.html passed > [2/2] fast/canvas/canvas-createPattern-video-modify.html failed unexpectedly (test timed out)
Created attachment 303047 [details] backtrace of web process Sometimes, fast/canvas/canvas-createPattern-video-loading.html timed out itself.
Created attachment 303049 [details] test gardening patch
Comment on attachment 303049 [details] test gardening patch Clearing flags on attachment: 303049 Committed r213216: <http://trac.webkit.org/changeset/213216>
All reviewed patches have been landed. Closing bug.
Reopen.
(In reply to comment #1) > Created attachment 303047 [details] > backtrace of web process > > Sometimes, fast/canvas/canvas-createPattern-video-loading.html timed out > itself. Is this bt from trunk? I think we had fixed this deadlock in r211815
(In reply to comment #6) > Is this bt from trunk? I think we had fixed this deadlock in r211815 Yes. I'm using trunk@213127
(In reply to comment #6) > (In reply to comment #1) > > Created attachment 303047 [details] > > backtrace of web process > > > > Sometimes, fast/canvas/canvas-createPattern-video-loading.html timed out > > itself. > > Is this bt from trunk? I think we had fixed this deadlock in r211815 I can reproduce it.
I think this is a GST bug, I remember I debugged similar issues in the past. The problem is that we need to set the pipeline state to NULL before all other elements are released. So, when the media player is destroyed we call gst_element_set_state(m_pipeline.get(), GST_STATE_NULL); and very often that blocks in internal GST mutexes. With our main thread blocked on this, any other thread waiting for a mutex held by the main thread will lock as well causing this deadlock.
Created attachment 303057 [details] Patch This patch fixes the timeout for me
Comment on attachment 303057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=303057&action=review As you're writing the code, it should be affecting other private players such as the WebRTC and the MSE ones. Please ensure that no tests are broken > Source/WebCore/ChangeLog:8 > + The timeout happens normally when the media player is and the pipeline state is set to NULL. The call to This first sentence does not make too much sense to me. > Source/WebCore/ChangeLog:10 > + happens with the smaple mutex used by VideoRenderRequestScheduler. VideoRenderRequestScheduler::requestRender() smaple -> sample. > Source/WebCore/ChangeLog:21 > + ~MediaPlayerPrivateGStreamerBase and ensure the draw timer and mutex is proplery cleaned up before. is proplery -> are properly
*** Bug 163850 has been marked as a duplicate of this bug. ***
*** Bug 169025 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Comment on attachment 303057 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=303057&action=review > > As you're writing the code, it should be affecting other private players > such as the WebRTC and the MSE ones. Please ensure that no tests are broken > > > Source/WebCore/ChangeLog:8 > > + The timeout happens normally when the media player is and the pipeline state is set to NULL. The call to > > This first sentence does not make too much sense to me. It doesn't make any sense :-) > > Source/WebCore/ChangeLog:10 > > + happens with the smaple mutex used by VideoRenderRequestScheduler. VideoRenderRequestScheduler::requestRender() > > smaple -> sample. > > > Source/WebCore/ChangeLog:21 > > + ~MediaPlayerPrivateGStreamerBase and ensure the draw timer and mutex is proplery cleaned up before. > > is proplery -> are properly
Committed r213224: <http://trac.webkit.org/changeset/213224>