167007 2017-01-13 09:52:12 -0800 REGRESSION(r210677): [GTK] Many layout test timeouts on GTK+ bots 2017-01-13 12:44:25 -0800 1 1 1 Unclassified WebKit Media WebKit Nightly Build PC Linux RESOLVED FIXED P2 Normal --- 1 mcatanzaro webkit-unassigned bugs-noreply calvaris clopez eocanha eric.carlson jer.noble mcatanzaro zan oldest_to_newest 1266483 0 mcatanzaro 2017-01-13 09:52:12 -0800 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. 1266484 1 mcatanzaro 2017-01-13 09:55:38 -0800 Committed r210732: <http://trac.webkit.org/changeset/210732> 1266543 2 jer.noble 2017-01-13 11:39:44 -0800 Can you please attach some of the test results that caused you to roll this patch out? 1266544 3 mcatanzaro 2017-01-13 11:51:27 -0800 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. 1266547 4 zan 2017-01-13 12:32:03 -0800 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. 1266550 5 jer.noble 2017-01-13 12:35:43 -0800 (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. 1266555 6 zan 2017-01-13 12:44:25 -0800 (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.