RESOLVED FIXED38011
Add code to help debug new-run-webkit-test hangs on the Chromium bots 
https://bugs.webkit.org/show_bug.cgi?id=38011
Summary Add code to help debug new-run-webkit-test hangs on the Chromium bots
Eric Seidel (no email)
Reported 2010-04-22 16:05:01 PDT
Add code to help debug new-run-webkit-test hangs on the Chromium bots
Attachments
Add code for debugging on the bots (5.51 KB, patch)
2010-04-22 16:07 PDT, Eric Seidel (no email) 		no flags
DetailsFormatted DiffDiff
Update comments and ChangeLog (5.75 KB, patch)
2010-04-22 16:27 PDT, Eric Seidel (no email) 		abarth: review+
abarth: commit-queue+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2010-04-22 16:07:36 PDT
Created attachment 54102 [details] Add code for debugging on the bots
Adam Barth
Comment 2 2010-04-22 16:09:32 PDT
Comment on attachment 54102 [details] Add code for debugging on the bots You haz no tests.
Eric Seidel (no email)
Comment 3 2010-04-22 16:11:36 PDT
Comment on attachment 54102 [details] Add code for debugging on the bots Too bad.
Eric Seidel (no email)
Comment 4 2010-04-22 16:13:16 PDT
Comment on attachment 54102 [details] Add code for debugging on the bots There is some question as to if we even want this code added in. Then there is question as to how one would go about testing his. We could stub out sys._current_frames(), maybe? Or we could have the test data depend on the implementation of python/unitest.py which seems like a bad idea.
Eric Seidel (no email)
Comment 5 2010-04-22 16:14:51 PDT
If this were C++ I would wrap it in some #ifdef with some big THIS_IS_A_HACK. But maybe we do want this code long term? Certainly we don't want it dumping every 60s I don't think. I would love if we could repro the failure locally, that woudl be better than checking in hacks like this just so we can debug on our bots.
Ojan Vafai
Comment 6 2010-04-22 16:18:56 PDT
Comment on attachment 54102 [details] Add code for debugging on the bots WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:648 + # through which tests we wait on. I don't understand this last sentence. WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:656 + # The individual threads already call update_summary. This is not true. The individual threads only call update_summary if we're running in single threaded mode. The individual threads do update the shared results_queue object that update_summary uses though.
Eric Seidel (no email)
Comment 7 2010-04-22 16:20:51 PDT
Wow. you're right. test_runner is None otherwise. Crazy.
Eric Seidel (no email)
Comment 8 2010-04-22 16:27:50 PDT
Created attachment 54106 [details] Update comments and ChangeLog
Adam Barth
Comment 9 2010-04-22 16:41:06 PDT
Comment on attachment 54106 [details] Update comments and ChangeLog This code is super mysterious to me so this is more of a rubber stamp. Also, i'd like to see it removed as soon as reasonable.
Eric Seidel (no email)
Comment 10 2010-04-22 16:45:36 PDT
Agreed.
Eric Seidel (no email)
Comment 11 2010-04-22 16:48:08 PDT
Committed r58128: <http://trac.webkit.org/changeset/58128>
Note You need to log in before you can comment on or make changes to this bug.