Bug 167007
Summary: | REGRESSION(r210677): [GTK] Many layout test timeouts on GTK+ bots | ||
---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
Component: | Media | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | bugs-noreply, calvaris, clopez, eocanha, eric.carlson, jer.noble, mcatanzaro, zan |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | PC | ||
OS: | Linux |
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
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.