new-run-webkit-tests does not correctly identify timeouts on Mac

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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)]

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]

I don't think this is an issue any more; closing. Please reopen (or file a new bug) if I'm mistaken.