-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
DEBUG_EXCEPTION_CATCH_HANDLER_FOUND events missing for exceptions caught by func-eval #102178
Comments
dotnet-policy-service
bot
added
the
untriaged
New issue has not been triaged by the area owner
label
May 13, 2024
Tagging subscribers to this area: @tommcdon |
janvorli
added a commit
to janvorli/runtime
that referenced
this issue
May 20, 2024
The VS team has recently reported two issues with the new exception handling in Visual Studio debugger. The first issue was that an unhandled exception on a secondary managed thread wasn't showing any stack trace when the exception occured and the debugger has broken in. The other issue was that when an exception occured during a funceval invoked from the immediate window, the debugger would not highlight the source line where the exception occured and it would not display a dialog with the exception details. Both problems were caused by the same underlying problem. In both cases, the "catch handler found" notification was to be sent at a point when the managed stack frames were already gone - in native code in catch / filter. In the funceval case, there was even a check that prevented sending the notification at all when there was no exception info present. The fix is to move the notification to the point where the managed stack frames are still present - when we detect in the EH code that there is no managed frame left and either the DebuggerU2MCatchHandler frame or FuncEvalFrame is the explicit frame we've encountered as the next one to process. The FuncEvalFrame case is a bit more involved, as we always push ProtectValueClassFrame after the FuncEvalFrame, so we need to skip that one in the check. The debugger actually needs to get a pointer to the FuncEvalFrame in the notification to do the right thing. Close dotnet#102178 and dotnet#101729
janvorli
added a commit
to janvorli/runtime
that referenced
this issue
May 20, 2024
The VS team has recently reported two issues with the new exception handling in Visual Studio debugger. The first issue was that an unhandled exception on a secondary managed thread wasn't showing any stack trace when the exception occured and the debugger has broken in. The other issue was that when an exception occured during a funceval invoked from the immediate window, the debugger would not highlight the source line where the exception occured and it would not display a dialog with the exception details. Both problems were caused by the same underlying problem. In both cases, the "catch handler found" notification was to be sent at a point when the managed stack frames were already gone - in native code in catch / filter. In the funceval case, there was even a check that prevented sending the notification at all when there was no exception info present. The fix is to move the notification to the point where the managed stack frames are still present - when we detect in the EH code that there is no managed frame left and either the DebuggerU2MCatchHandler frame or FuncEvalFrame is the explicit frame we've encountered as the next one to process. The FuncEvalFrame case is a bit more involved, as we always push ProtectValueClassFrame after the FuncEvalFrame, so we need to skip that one in the check. The debugger actually needs to get a pointer to the FuncEvalFrame in the notification to do the right thing. Close dotnet#102178 and dotnet#101729
janvorli
added a commit
that referenced
this issue
May 21, 2024
* Fix VS debugger issues with funceval and secondary threads The VS team has recently reported two issues with the new exception handling in Visual Studio debugger. The first issue was that an unhandled exception on a secondary managed thread wasn't showing any stack trace when the exception occured and the debugger has broken in. The other issue was that when an exception occured during a funceval invoked from the immediate window, the debugger would not highlight the source line where the exception occured and it would not display a dialog with the exception details. Both problems were caused by the same underlying problem. In both cases, the "catch handler found" notification was to be sent at a point when the managed stack frames were already gone - in native code in catch / filter. In the funceval case, there was even a check that prevented sending the notification at all when there was no exception info present. The fix is to move the notification to the point where the managed stack frames are still present - when we detect in the EH code that there is no managed frame left and either the DebuggerU2MCatchHandler frame or FuncEvalFrame is the explicit frame we've encountered as the next one to process. The FuncEvalFrame case is a bit more involved, as we always push ProtectValueClassFrame after the FuncEvalFrame, so we need to skip that one in the check. The debugger actually needs to get a pointer to the FuncEvalFrame in the notification to do the right thing. Close #102178 and #101729 * Fix too strong assert The ProtectValueClassFrame can also occur without FuncEvalFrame in the reflection invocation.
Ruihan-Yin
pushed a commit
to Ruihan-Yin/runtime
that referenced
this issue
May 30, 2024
…2470) * Fix VS debugger issues with funceval and secondary threads The VS team has recently reported two issues with the new exception handling in Visual Studio debugger. The first issue was that an unhandled exception on a secondary managed thread wasn't showing any stack trace when the exception occured and the debugger has broken in. The other issue was that when an exception occured during a funceval invoked from the immediate window, the debugger would not highlight the source line where the exception occured and it would not display a dialog with the exception details. Both problems were caused by the same underlying problem. In both cases, the "catch handler found" notification was to be sent at a point when the managed stack frames were already gone - in native code in catch / filter. In the funceval case, there was even a check that prevented sending the notification at all when there was no exception info present. The fix is to move the notification to the point where the managed stack frames are still present - when we detect in the EH code that there is no managed frame left and either the DebuggerU2MCatchHandler frame or FuncEvalFrame is the explicit frame we've encountered as the next one to process. The FuncEvalFrame case is a bit more involved, as we always push ProtectValueClassFrame after the FuncEvalFrame, so we need to skip that one in the check. The debugger actually needs to get a pointer to the FuncEvalFrame in the notification to do the right thing. Close dotnet#102178 and dotnet#101729 * Fix too strong assert The ProtectValueClassFrame can also occur without FuncEvalFrame in the reflection invocation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
In .NET 9, exceptions caught by the debugger's func-eval backstop no longer raise
DEBUG_EXCEPTION_CATCH_HANDLER_FOUND
notifications when they are caught. This does NOT happen if DOTNET_LegacyExceptionHandling is enabled.Reproduction Steps
Divide(5, 0)
in the debugger. If using Visual Studio, use the immediate Window so that the debugger will stop on the exceptionExpected behavior
ICorDebug should raise an exception callback with
DEBUG_EXCEPTION_CATCH_HANDLER_FOUND
. In Visual Studio, if evaluating from the immediate Window, this will cause the debugger to break on the exception.Actual behavior
No catch-handler-found event is raised
Regression?
Regression from .NET 8
Known Workarounds
Use legacy exception handling.
Configuration
Issue reproduces on Windows x64 and does not reproduce on Windows x86. I didn't try any other configurations.
Other information
No response
The text was updated successfully, but these errors were encountered: