inspector/debugger-pause-on-breakpoint.html is timing out on Windows
<rdar://problem/8501936>
Looks like a problem with the bot. http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=inspector%2Fdebugger
(In reply to comment #2) > Looks like a problem with the bot. > > http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=inspector%2Fdebugger I don't know how to interpret that graph. But are any of those machines running Apple's Windows port? If not, isn't it possible that a bug exists in Apple/Windows-specific code?
(In reply to comment #3) > (In reply to comment #2) > > Looks like a problem with the bot. > > > > http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=inspector%2Fdebugger > > I don't know how to interpret that graph. But are any of those machines running Apple's Windows port? If not, isn't it possible that a bug exists in Apple/Windows-specific code? I don't think it's a bug, that's just a flakiness. The dashboard shows strange slowness on win debug bot, while all changes for that range look absolutely innocent. After a while, that slowness just gone, again without any reason.
win debug bot lag
Closing the bug because the bot is laggy isn't the right thing to do. After all, we haven't fixed the problem! If this is a bug in the test harness or the bot, the right thing to do is to move this bug to the Tools/Tests component (which I've now done).
The timeout for notifyDone is 15 seconds, which is pretty long for a single test to take, even if the bot is being slow. Is there something we can do to make the test shorter? In the past we've broken up long-running tests into multiple shorter tests. Could we do that here?
(In reply to comment #7) > The timeout for notifyDone is 15 seconds, which is pretty long for a single test to take, even if the bot is being slow. Is there something we can do to make the test shorter? In the past we've broken up long-running tests into multiple shorter tests. Could we do that here? 15 seconds is definitely enough for the test. The problem must be in the test itself or in the inspector debugger tests infrastructure in general, anyways if fails quite often and we can reproduce it we should fix this.
*** This bug has been marked as a duplicate of bug 45291 ***