Bug 169019 – [GTK] fast/canvas/canvas-createPattern-video-loading.html makes its subsequent test timeout

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Fujii Hironori]

[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)

[Fujii Hironori]

Created attachment 303047 [details]
backtrace of web process

Sometimes, fast/canvas/canvas-createPattern-video-loading.html timed out itself.

[Fujii Hironori]

Created attachment 303049 [details]
test gardening patch

[WebKit Commit Bot]

Comment on attachment 303049 [details]
test gardening patch

Clearing flags on attachment: 303049

Committed r213216: <http://trac.webkit.org/changeset/213216>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Fujii Hironori]

Reopen.

[Carlos Garcia Campos]

(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

[Fujii Hironori]

(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

[Carlos Garcia Campos]

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

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

Created attachment 303057 [details]
Patch

This patch fixes the timeout for me

[Xabier Rodríguez Calvar]

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

[Carlos Garcia Campos]

*** Bug 163850 has been marked as a duplicate of this bug. ***

[Carlos Garcia Campos]

*** Bug 169025 has been marked as a duplicate of this bug. ***

[Carlos Garcia Campos]

(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

[Carlos Garcia Campos]

Committed r213224: <http://trac.webkit.org/changeset/213224>