[crash] Catch exception for Debugger Crash test, reenable #11438
Conversation
|
@akoeplinger you filed #11385 . I see two failures linked there. I've re-enabled the test here but changed it to catch the exception in question. If we've got an issue with the flake rate being too high, there are some heuristics we can tune here to improve the reliability of the handler. There's a scalar "wait" argument passed to the dumper that's |
|
As this is a newly added test, it should not be flaky. |
|
@vargaz I agree with you. But the question is how often is it happening. If we see a very rare failure, I think that reflects an unavoidable instability in doing something like this while crashing. If it's happening more often, that means we need to make the mechanism more reliable. |
|
Since the crash happens in a very controlled environment, the test should be reliably in theory. |
|
I think we're depending on the debugger sending the event before the socket is closed, which doesn't happen in some cases. The problem is that there's a lot of delayed queueing of event sending. I think I can throw together something that will deterministically keep the VM alive until that socket can be closed and things can shut down. |
|
I've been trying to reproduce on many machines for more than 14 hours and I haven't seen one test failure of this type. Using x64, x32, and armv7 |
|
@alexanderkyte should we try merging this and see if the flakiness is resolved? |
| vm = null; | ||
| } | ||
| } catch (VMDisconnectedException exc) { | ||
| Assert.Fail ("Got VMDisconnectedException rather than crash event"); |
There was a problem hiding this comment.
It's better to let the exception go through in that case, so we know what's the root failure.
You should keep part of the previously existing code, while still adding what you have here, as followed:
} finally {
try {
vm.Detach ();
} catch (VMDisconnectedException) {
// This is fine
} finally {
vm = null;
}
}
|
I want to re-enable this test after #12125 is merged and green. |
|
Closing because #12304 merged |
This might be enough if the problem was with the uncaught exceptions.
For continued flake risks, can we have a tighter bound on how often this is flaking? We should be able to handle it with some retries. If it's flaking more often than that, a post-send pause might need to be enabled on the debuggee side.