63981 2011-07-06 02:02:19 -0700 new-run-webkit-tests does not correctly identify timeouts on Mac 2012-06-08 15:59:46 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 70435 64491 1 eric webkit-unassigned abarth dpranke ojan oldest_to_newest 432689 0 eric 2011-07-06 02:02:19 -0700 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. 486946 1 eric 2011-10-19 13:26:25 -0700 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. 489428 2 eric 2011-10-24 10:38:16 -0700 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. 645100 3 dpranke 2012-06-08 15:59:46 -0700 I don't think this is an issue any more; closing. Please reopen (or file a new bug) if I'm mistaken.