ReportCrash destabilizes new-run-webkit-tests
Created attachment 99445 [details] Patch
Comment on attachment 99445 [details] Patch Clearing flags on attachment: 99445 Committed r90246: <http://trac.webkit.org/changeset/90246>
All reviewed patches have been landed. Closing bug.
Comment on attachment 99445 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=99445&action=review > Tools/Scripts/webkitpy/layout_tests/layout_package/manager.py:671 > + if self._port.executive().running_pids(self._port.is_crash_reporter): This call is expensive. How often do we run this?
CCing ossy in case this slows down the Qt bots again.
> This call is expensive. How often do we run this? Once a second. If it turns out to be a problem, I have an idea how to optimize it.
It's not entirely clear to me why ReportCrash would destablize the run, since DRT should theoretically be taking up 100% of the CPU before it crashes, so the fact that ReportCrash is taking up 100% of that core in DRT's stead should be OK. Do we run more DRTs than we have cores? (Actually I think we run 2x iirc?)
Maybe it's something specific to my system? ReportCrash make the UI in all my programs sluggish, maybe because causing the kernel to do a lot of work somehow? Anecdotally, this patch has been a big stability win on my machine. Crashes in some tests used to trigger other tests to timeout, and that doesn't happen anymore.
Comment on attachment 99445 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=99445&action=review > Tools/Scripts/webkitpy/layout_tests/layout_package/single_test_runner.py:132 > + self._port.executive().wait_newest(self._port.is_crash_reporter) You might want to wait for the crash reporter in worker._run_test instead, since you can do in between tests (when the test timeout does not apply).
> You might want to wait for the crash reporter in worker._run_test instead, since you can do in between tests (when the test timeout does not apply). https://bugs.webkit.org/show_bug.cgi?id=63837