Skip to content
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

Closed
gregg-miskelly opened this issue May 13, 2024 · 2 comments · Fixed by #102470
Closed
Assignees
Milestone

Comments

@gregg-miskelly
Copy link
Contributor

gregg-miskelly commented May 13, 2024

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

  1. Create the following program targeting .NET 9
  2. Set a breakpoint on the specified line
  3. Evaluate Divide(5, 0) in the debugger. If using Visual Studio, use the immediate Window so that the debugger will stop on the exception
using System.Diagnostics;

static class Program
{
    static int Divide(int n, int m)
    {
        return n / m;
    }

    static void Main(string[] args)
    {
        Console.WriteLine("10/2 = {0}", Divide(10, 2)); // breakpoint here
    }
};

Expected 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

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label May 13, 2024
Copy link
Contributor

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

@tommcdon
Copy link
Member

@janvorli

@tommcdon tommcdon added this to the 9.0.0 milestone May 15, 2024
@tommcdon tommcdon removed the untriaged New issue has not been triaged by the area owner label May 15, 2024
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants