Add code to help debug new-run-webkit-test hangs on the Chromium bots
Created attachment 54102 [details] Add code for debugging on the bots
Comment on attachment 54102 [details] Add code for debugging on the bots You haz no tests.
Comment on attachment 54102 [details] Add code for debugging on the bots Too bad.
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.
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.
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.
Wow. you're right. test_runner is None otherwise. Crazy.
Created attachment 54106 [details] Update comments and ChangeLog
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.
Agreed.
Committed r58128: <http://trac.webkit.org/changeset/58128>