-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Corrupting exceptions are not turned into fail fasts #103018
Labels
area-ExceptionHandling-coreclr
blocking-clean-ci
Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Milestone
Comments
This blocks post-mortem debugging of CI crashes caused by access violations (e.g. see #102919). |
I've found the culprit, missing handling of access violation as a failfast in the GetClasslibException. I'll fix it. |
janvorli
added a commit
to janvorli/runtime
that referenced
this issue
Jun 4, 2024
The new EH is not correctly handling corrupting state exceptions. Instead of failing fast, the exceptions are actually handled like other exceptions and can be caught by the user code. This change fixes it. Besides fixing the issue, I had to introduce a way to trim exception handling code frames from the stack trace reported by the failfast, otherwise the output would be confusing. As an additional change, I've noticed that hardware exceptions under WinDbg don't trigger the WinDbg first chance exception mechanism. I've recently fixed the same for software exceptions, this adds the same for hardware ones. Close dotnet#103018
janvorli
added a commit
that referenced
this issue
Jun 5, 2024
* Fix handling of corrupting state exceptions The new EH is not correctly handling corrupting state exceptions. Instead of failing fast, the exceptions are actually handled like other exceptions and can be caught by the user code. This change fixes it. Besides fixing the issue, I had to introduce a way to trim exception handling code frames from the stack trace reported by the failfast, otherwise the output would be confusing. As an additional change, I've noticed that hardware exceptions under WinDbg don't trigger the WinDbg first chance exception mechanism. I've recently fixed the same for software exceptions, this adds the same for hardware ones. Close #103018 * Remove the WinDbg first chance notification
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
area-ExceptionHandling-coreclr
blocking-clean-ci
Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Repro:
It should not be possible to catch corrupting exceptions like AccessViolationExceptions.
Actual behavior
Here
Expected behavior
Known Issue Error Message
Fill the error message using step by step known issues guidance.
Report
Summary
The text was updated successfully, but these errors were encountered: