Summary: | new-run-webkit-tests is not correctly catching/printing TestRunInterruptedException | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
Component: | Tools / Tests | Assignee: | Dirk Pranke <dpranke> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | abarth, aroben, dpranke, rniwa |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | 64218 | ||
Bug Blocks: | 64491 |
Description
Eric Seidel (no email)
2011-07-06 03:36:23 PDT
Hm, It looks like the code mostly worked. The debug code prints the stack trace of any exception it gets on the worker. Perhaps your comment about "silently" means you wouldn't expect to see this? But, you're right that we don't seem to be catching the exception and printing the log message, so it's unclear which code path fired on the way out. It looks like the gtk port is running w/o multiple workers, using --worker-model=inline, so this should be trivial to test/reproduce. We have a test for this in run_webkit_tests_integrationtest.py: test_exit_after_n_crashes that you can probably debug or try on the command line to see what happens. Okay, this bug has to do with the interactions of exceptions (the way they are sent across the message queue) and the worker models. The patch I've uploaded to bug 64218 should fix this as well. Also, this only happens with --worker-model=inline, which we probably shouldn't be using on the bots. There's no reason for this to block the NRWT cutover, so I'm clearing that. This affects how crashes are displayed on the bots. I'm closing this, since I think this was fixed in r90679. Please re-open (or file a new bug) if there's still an issue. OK. We'll know if the bots get confused by many crashes. |