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.
Committed r210732: <http://trac.webkit.org/changeset/210732>
Can you please attach some of the test results that caused you to roll this patch out?
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.
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.
(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.
(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.