RESOLVED FIXED95097
[NRWT] XvfbDriver should stop the Xvfb more aggressively
https://bugs.webkit.org/show_bug.cgi?id=95097
Summary [NRWT] XvfbDriver should stop the Xvfb more aggressively
Zan Dobersek
Reported 2012-08-27 10:03:22 PDT
When XvfbDriver is stopping, it tries to shut down its Xvfb instance in a 'polite' way, by calling terminate(). This doesn't always succeed, with the layout-tests step in the builders timing out: http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release/builds/28021 (Admittedly blaming the Xvfb is just a very good guess, I can't confirm this myself though.) The hisorical GtkDriver (on which the XvfbDriver is based) used to be more aggressive, killing Xvfb unconditionally[1]. I recommend following this behavior, but using the Executive class to kill the process. For good measure and (again based on guessing) to get rid of the continuous trouble of tests timing out on the GTK 64-bit Debug builder[2], I also recommend killing any stale Xvfb instances through the kill-old-processes script[3] [1] http://trac.webkit.org/changeset/116212 [2] http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug [3] http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/kill-old-processes
Attachments
Patch (2.30 KB, patch)
2012-08-27 10:54 PDT, Zan Dobersek
no flags
Patch (12.43 KB, patch)
2012-08-28 09:14 PDT, Zan Dobersek
no flags
Patch (13.11 KB, patch)
2012-09-06 00:28 PDT, Zan Dobersek
no flags
Zan Dobersek
Comment 1 2012-08-27 10:54:14 PDT
Eric Seidel (no email)
Comment 2 2012-08-27 13:13:14 PDT
Comment on attachment 160746 [details] Patch There must be a better way to get an executive object than makign a new one. Also, this should be tested.
Zan Dobersek
Comment 3 2012-08-28 09:14:50 PDT
Dirk Pranke
Comment 4 2012-08-28 12:39:09 PDT
Comment on attachment 160995 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=160995&action=review > Tools/Scripts/webkitpy/layout_tests/port/xvfbdriver.py:72 > + self._port.host.executive.kill_process(self._xvfb_process.pid) do we know why terminate() isn't working?
Zan Dobersek
Comment 5 2012-08-29 01:24:46 PDT
(In reply to comment #4) > (From update of attachment 160995 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=160995&action=review > > > Tools/Scripts/webkitpy/layout_tests/port/xvfbdriver.py:72 > > + self._port.host.executive.kill_process(self._xvfb_process.pid) > > do we know why terminate() isn't working? Unfortunately I can't give a good answer here. I'm not able to reproduce the problem locally and don't have access to the builders. Again, blaming Xvfb(Driver) is at the moment just a very good guess as it's one thing that the GTK port uses for testing that other ports don't, and the NRWT stops giving output around the Xvfb termination in the last Driver object.
Dirk Pranke
Comment 6 2012-08-29 16:29:37 PDT
I see. That's unfortunate.
Zan Dobersek
Comment 7 2012-09-06 00:28:10 PDT
Created attachment 162434 [details] Patch Also removes the lock file for the display after Xvfb process is killed.
Zan Dobersek
Comment 8 2012-09-06 00:55:57 PDT
(In reply to comment #7) > Created an attachment (id=162434) [details] > Patch > > Also removes the lock file for the display after Xvfb process is killed. To elaborate, I though using -nolock would suffice for this, but that option only functions when the Xvfb is run with root privileges, which should probably be avoided.
Zan Dobersek
Comment 9 2012-09-07 03:00:42 PDT
Comment on attachment 162434 [details] Patch Clearing flags on attachment: 162434 Committed r127849: <http://trac.webkit.org/changeset/127849>
Zan Dobersek
Comment 10 2012-09-07 03:00:47 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.