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

Should stack traces collected in filters have managed EH frames in them? #107995

Closed
SingleAccretion opened this issue Sep 18, 2024 · 2 comments · Fixed by #108723
Closed

Should stack traces collected in filters have managed EH frames in them? #107995

SingleAccretion opened this issue Sep 18, 2024 · 2 comments · Fixed by #108723
Assignees
Labels
area-ExceptionHandling-coreclr in-pr There is an active PR which will close this issue when it is merged
Milestone

Comments

@SingleAccretion
Copy link
Contributor

SingleAccretion commented Sep 18, 2024

Reproduction:

TestStackTraceInFilter();

[MethodImpl(MethodImplOptions.NoInlining)]
static void TestStackTraceInFilter()
{
    StackTrace st = TestStackTraceInFilterCallee();
    Console.WriteLine(st);
}

[MethodImpl(MethodImplOptions.NoInlining)]
static StackTrace TestStackTraceInFilterCallee()
{
    StackTrace st = null;
    try
    {
        throw new Exception();
    }
    catch (Exception e) when ((st = new StackTrace(fNeedFileInfo: true)) != null)
    {
    }
    return st;
}

dotnet run -f net8.0:

   at RyuJitReproduction.Program.TestStackTraceInFilterCallee() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 94
   at RyuJitReproduction.Program.TestStackTraceInFilterCallee() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 92
   at RyuJitReproduction.Program.TestStackTraceInFilter() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 76
   at RyuJitReproduction.Program.Main() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 70

dotnet run -f net9.0:

   at RyuJitReproduction.Program.TestStackTraceInFilterCallee() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 94
   at System.Runtime.EH.FindFirstPassHandler(Object exception, UInt32 idxStart, StackFrameIterator& frameIter, UInt32& tryRegionIdx, Byte*& pHandler)
   at System.Runtime.EH.DispatchEx(StackFrameIterator& frameIter, ExInfo& exInfo)
   at System.Runtime.EH.RhThrowEx(Object exceptionObj, ExInfo& exInfo)
   at RyuJitReproduction.Program.TestStackTraceInFilterCallee() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 92
   at RyuJitReproduction.Program.TestStackTraceInFilter() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 76
   at RyuJitReproduction.Program.Main() in C:\Users\Accretion\source\dotnet\RyuJit\RyuJitReproduction\Program.cs:line 70

I would also slightly question the double appearance of TestStackTraceInFilterCallee where other funclets get collapsed, but I suppose that has been this way for a long time.

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Sep 18, 2024
@mangod9
Copy link
Member

mangod9 commented Sep 18, 2024

this looks related to new EH. Assume you get 8.0 if that is disabled? @janvorli fyi.

@mangod9 mangod9 removed the untriaged New issue has not been triaged by the area owner label Sep 18, 2024
@mangod9 mangod9 added this to the 9.0.0 milestone Sep 18, 2024
@SingleAccretion
Copy link
Contributor Author

Assume you get 8.0 if that is disabled?

Correct.

janvorli added a commit to janvorli/runtime that referenced this issue Oct 9, 2024
When StackTrace is created inside of an exception filter, it contains
stack frames of the managed exception handling code, like
System.Runtime.EH.RhThrowEx
System.Runtime.EH.DispatchEx
System.Runtime.EH.FindFirstPassHandler

These should not occur on the stack trace as they are internal
implementation detail of the new EH.

This change fixes it by adding [StackTraceHidden] attribute to these
methods.

Close dotnet#107995
@dotnet-policy-service dotnet-policy-service bot added in-pr There is an active PR which will close this issue when it is merged labels Oct 9, 2024
github-actions bot pushed a commit that referenced this issue Oct 14, 2024
When StackTrace is created inside of an exception filter, it contains
stack frames of the managed exception handling code, like
System.Runtime.EH.RhThrowEx
System.Runtime.EH.DispatchEx
System.Runtime.EH.FindFirstPassHandler

These should not occur on the stack trace as they are internal
implementation detail of the new EH.

This change fixes it by adding [StackTraceHidden] attribute to these
methods.

Close #107995
jeffschwMSFT added a commit that referenced this issue Oct 15, 2024
When StackTrace is created inside of an exception filter, it contains
stack frames of the managed exception handling code, like
System.Runtime.EH.RhThrowEx
System.Runtime.EH.DispatchEx
System.Runtime.EH.FindFirstPassHandler

These should not occur on the stack trace as they are internal
implementation detail of the new EH.

This change fixes it by adding [StackTraceHidden] attribute to these
methods.

Close #107995

Co-authored-by: Jan Vorlicek <[email protected]>
Co-authored-by: Jeff Schwartz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-ExceptionHandling-coreclr in-pr There is an active PR which will close this issue when it is merged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants