Bug 167007 – REGRESSION(r210677): [GTK] Many layout test timeouts on GTK+ bots

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Michael Catanzaro]

Many layout test timeouts on GTK+ bots since r210677:

eocanha:  I don't know if the problem is the change to RefPtr: https://github.com/WebKit/webkit/commit/0518d272dac9ec8de8ed08789756a0826472de17#diff-7da59705d8926b4b5a36864845e675d8R888
eocanha:  or the usage if a null media player client: https://github.com/WebKit/webkit/commit/0518d272dac9ec8de8ed08789756a0826472de17#diff-08dab6b222f92a2b21cf992f5d689f53R164

eocanha:  but it's the typical kind of things related to object destruction. They don't manifest in the test which uses the video tag, but in the following one, as that kind of destructions are deferred sometimes.

Rolling out manually because webkitbot is broken. Not reopening the original bug because I don't have access.

[Michael Catanzaro]

Committed r210732: <http://trac.webkit.org/changeset/210732>

[Jer Noble]

Can you please attach some of the test results that caused you to roll this patch out?

[Michael Catanzaro]

Sure, see:

https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/r210678%20(20201)/results.html

The problem is too many media tests timing out.

I notice two different forms of stderr output from several of the media tests. The first is:

(WebKitWebProcess:7612): GStreamer-CRITICAL **: gst_bin_get_by_name: assertion 'GST_IS_BIN (bin)' failed

which is not very useful, and might be a preexisting issue. Carlos Lopez, perhaps we could run our tests with G_DEBUG=fatal-criticals to we can get backtraces instead of just warnings? At least in debug mode.

The other form of output is this the following text, repeated tens of thousands of times for each of several media tests:

FAIL: TestControllerRunLoop timed out.

I suspect that is the problem.

[Zan Dobersek]

The problem is we're always querying MediaPlayerClient whether we can perform accelerated rendering in MediaPlayerPrivateGStreamerBase. When the MediaPlayerClient object is changed to the null one, this results in a lockup and timeout of WKTR. I'll post a patch.

[Jer Noble]

(In reply to comment #4)
> The problem is we're always querying MediaPlayerClient whether we can
> perform accelerated rendering in MediaPlayerPrivateGStreamerBase. When the
> MediaPlayerClient object is changed to the null one, this results in a
> lockup and timeout of WKTR. I'll post a patch.

Okay, interesting.  Any time where you are now calling into NullMediaPlayerClient is a time where previously you were calling from a an object whose memory has been freed.

[Zan Dobersek]

(In reply to comment #5)
> (In reply to comment #4)
> > The problem is we're always querying MediaPlayerClient whether we can
> > perform accelerated rendering in MediaPlayerPrivateGStreamerBase. When the
> > MediaPlayerClient object is changed to the null one, this results in a
> > lockup and timeout of WKTR. I'll post a patch.
> 
> Okay, interesting.  Any time where you are now calling into
> NullMediaPlayerClient is a time where previously you were calling from a an
> object whose memory has been freed.

Fun. The patch is at bug #167015.