RESOLVED FIXED Bug 63981
new-run-webkit-tests does not correctly identify timeouts on Mac 
https://bugs.webkit.org/show_bug.cgi?id=63981
Summary new-run-webkit-tests does not correctly identify timeouts on Mac
Eric Seidel (no email)
Reported 2011-07-06 02:02:19 PDT
new-run-webkit-tests does not correctly identify timeouts on Mac Example: 2011-07-06 01:55:41,276 43149 printing.py:470 INFO 10 slowest tests that are not marked as SLOW and did not timeout/crash: 2011-07-06 01:55:41,276 43149 printing.py:470 INFO fast/workers/storage/interrupt-database.html took 30.0 seconds 2011-07-06 01:55:41,276 43149 printing.py:470 INFO fast/workers/worker-close-more.html took 30.0 seconds 2011-07-06 01:55:41,276 43149 printing.py:470 INFO fast/workers/shared-worker-frame-lifecycle.html took 30.0 seconds 2011-07-06 01:55:41,276 43149 printing.py:470 INFO fast/workers/shared-worker-lifecycle.html took 30.0 seconds 2011-07-06 01:55:41,276 43149 printing.py:470 INFO fast/workers/worker-lifecycle.html took 30.0 seconds What's happening is that we're not reading stderr correctly in ServerProcess, so we never see the timeout notification. At least I think that's what's happening. I believe this to be very related to bug 63683. Which is about listening for #CRASHED correctly on stderr.
Attachments
Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2011-10-19 13:26:25 PDT
I'm not sure my original theory was correct. I don't see any #TIMEOUT notifications over stderr. However, once bug 70435 lands, this would be very easy to fix were there #TIMEOUT notifications in stderr.
Eric Seidel (no email)
Comment 2 2011-10-24 10:38:16 PDT
I'm moving this to the polish bug, since it's clearly not stopped us from switching the mac bots. I'm not sure this is still an issue.
Dirk Pranke
Comment 3 2012-06-08 15:59:46 PDT
I don't think this is an issue any more; closing. Please reopen (or file a new bug) if I'm mistaken.
Note You need to log in before you can comment on or make changes to this bug.