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

[native aot] Unhandled exceptions are not printed to console #91298

Closed
jkotas opened this issue Aug 29, 2023 · 3 comments · Fixed by #91415
Closed

[native aot] Unhandled exceptions are not printed to console #91298

jkotas opened this issue Aug 29, 2023 · 3 comments · Fixed by #91415
Assignees
Milestone

Comments

@jkotas
Copy link
Member

jkotas commented Aug 29, 2023

Compile and run with nativeaot on current main:

throw new Exception("My unhandled exception");

Expected result

Unhandled exception message is printed to console.

Actual result

No message printed to console

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Aug 29, 2023
@jkotas jkotas removed the untriaged New issue has not been triaged by the area owner label Aug 29, 2023
@ghost
Copy link

ghost commented Aug 29, 2023

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile and run with nativeaot on current main:

throw new Exception("My unhandled exception");

Expected result

Unhandled exception message is printed to console.

Actual result

No message printed to console

Author: jkotas
Assignees: -
Labels:

area-NativeAOT-coreclr

Milestone: -

@jkotas
Copy link
Member Author

jkotas commented Aug 29, 2023

Looks like a regression from #88034. @janvorli Could you please take a look?

@janvorli
Copy link
Member

The problem is really caused by the #88034, specifically by moving the

prevControlPC = frameIter.ControlPC;
prevOriginalPC = frameIter.OriginalControlPC;

from after to before the

It results in call to the UnhandledExceptionFailFastViaClasslib with prevOriginalPC that's one level up the call stack, in the native wmain. That further causes the InternalCalls.RhpGetClasslibFunctionFromCodeAddress to return null, as the address is not in managed code.

I can make this part of the change specific to coreclr, that fixes the problem. However, I would like to check what was the reason for moving it, it seems that for coreclr the only place where it matters is the arm64 code path here:

#if TARGET_ARM64
&& (frameIter.ControlPC == prevControlPC)
#endif

@MichalStrehovsky MichalStrehovsky added this to the 9.0.0 milestone Aug 31, 2023
janvorli added a commit to janvorli/runtime that referenced this issue Aug 31, 2023
The recent change to add a new exception handling mechanism to coreclr
has broken stack traces on unhandled exceptions in nativeaot.

This change fixes it by reverting the part of the change that caused the
problem and that turned out to not to be needed for the new exception
handling either.

Close dotnet#91298
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Aug 31, 2023
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Sep 5, 2023
jkotas pushed a commit that referenced this issue Sep 5, 2023
* Fix NativeAOT unhandled exception stack trace

The recent change to add a new exception handling mechanism to coreclr
has broken stack traces on unhandled exceptions in nativeaot.

This change fixes it by reverting the part of the change that caused the
problem and that turned out to not to be needed for the new exception
handling either.

Close #91298

* Add unhandled exception test

* Reflect PR feedback

* Fix Mono console log parsing
@ghost ghost locked as resolved and limited conversation to collaborators Oct 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants