Bug 31022 – DumpRenderTree should refuse to start when it can't contact the window server

• Component: Tools / Tests
• Status: NEW

[Evan Martin]

I mostly hack on WebKit from a Linux box; when it's time to make the final patch I push it over to a Mac box to run the layout tests.  These tests fail because you need to VNC into the Mac box for layout tests.  However, the failure mode is very confusing -- the tests just crash.

We should make DumpRenderTree check on whatever thing it needs to not crash and then have run-webkit-tests check this and abort if it's not set up right.

[Eric Seidel (no email)]

Would be nice to have.  Not sure when/if I'll ever get around to it.  CCing other folks who might have an opinion.

[Evan Martin]

Also, if anyone has pointers on the appropriate APIs to check this sort of thing, I might cook up a patch myself.  I know very little about Mac windowing stuff, which is why my bug report is so nondescriptive.

I imagine something like a "DumpRenderTree --check" that uses its exit code to indicate stuff is not set up right.

[Mark Rowe (bdash)]

(In reply to comment #0)
> I mostly hack on WebKit from a Linux box; when it's time to make the final
> patch I push it over to a Mac box to run the layout tests.  These tests fail
> because you need to VNC into the Mac box for layout tests.  However, the
> failure mode is very confusing -- the tests just crash.

Do the tests crash or simply fail?

[Evan Martin]

Here's after I VNC'd in, logged myself out, and then via ssh ran "run-webkit-tests fast/css":

Running tests from /Users/evanm/chrome/src/third_party/WebKit/LayoutTests
Testing 311 test cases.
fast/css .
fast/css/001.html -> crashed
^C

[Mark Rowe (bdash)]

Can you attach one of the crash logs from the crashes then?  <http://webkit.org/quality/crashlogs.html>

[Evan Martin]

Created attachment 42336 [details]
crash log

[Mark Rowe (bdash)]

Comment on attachment 42336 [details]
crash log

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'

Thread 0 Crashed:
0   com.apple.CoreFoundation      	0x92575e94 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 4
1   libobjc.A.dylib               	0x92ed4e3b objc_exception_throw + 40
2   com.apple.CoreFoundation      	0x92575dcb +[NSException raise:format:arguments:] + 155
3   com.apple.CoreFoundation      	0x92575e0a +[NSException raise:format:] + 58
4   com.apple.AppKit              	0x96caf0a7 _NXCreateWindow + 310
5   com.apple.AppKit              	0x96dda0b7 _NSCreateWindow + 58
6   com.apple.AppKit              	0x96d0db77 -[NSWindow _commonAwake] + 1953
7   com.apple.AppKit              	0x96d1231a -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 609
8   com.apple.AppKit              	0x96d1205c -[NSWindow orderWindow:relativeTo:] + 105
9   com.apple.AppKit              	0x972700fd -[NSWindow orderBack:] + 50
10  DumpRenderTree                	0x00007307 createWebViewAndOffscreenWindow() + 781

It may be that wrapping an exception handler around the code that sets up the window is a sufficiently easy way to determine whether we have the necessary connections.