RESOLVED FIXED 140218
When WebProcess is slow to respond to IPC, that's mistakenly reported as crash
https://bugs.webkit.org/show_bug.cgi?id=140218
Summary When WebProcess is slow to respond to IPC, that's mistakenly reported as crash
Alexey Proskuryakov
Reported 2015-01-07 15:25:56 PST
When WebKitTestRunner doesn't get a response to IPC, it dumps "#PROCESS UNRESPONSIVE" to stderr. When run-webkit-tests sees that, it for some reason reports the test as crashing. It seems like there may have been ports that couldn't detect crashes (chromium perhaps?). However, detecting crashes is a core WebKit2 behavior, and if that doesn't work, we shouldn't be lying about that in run-webkit-tests. There are practical cases where IPC takes a long time and triggers this - e.g. with ASan builds, despite them now having a higher IPC timeout. Generating accurate output will help reduce confusion.
Attachments
proposed fix (9.42 KB, patch)
2015-01-07 15:33 PST, Alexey Proskuryakov
darin: review+
Alexey Proskuryakov
Comment 1 2015-01-07 15:33:15 PST
Created attachment 244211 [details] proposed fix
Darin Adler
Comment 2 2015-01-07 20:47:22 PST
Comment on attachment 244211 [details] proposed fix View in context: https://bugs.webkit.org/attachment.cgi?id=244211&action=review > Tools/WebKitTestRunner/TestController.cpp:1392 > + fputs("#CRASHED - %s\n", webProcessName(), stderr); This needs to be changed to fprintf.
Alexey Proskuryakov
Comment 3 2015-01-08 09:10:29 PST
Alexey Proskuryakov
Comment 4 2015-01-08 09:48:08 PST
Looking into webkitpy failures - I forgot to run these tests. We really need to have them on EWS.
Alexey Proskuryakov
Comment 5 2015-01-08 10:02:23 PST
Fixed the failures in r178118.
Note You need to log in before you can comment on or make changes to this bug.