Fix thread abort issue with funceval #118354
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is a problem with threadabort in funceval in case there is no managed frame on the stack between the abortion point and the `FuncEvalFrame`. That can happen e.g. when invoking a static method via funceval for a type with static constructor that was not invoked yet and takes a long time to complete. The problem is caused by the fact that when EH is called to propagate the ThreadAbortException, it starts at the first managed frame and so it skips the try/catch in the funceval native code. This change fixes it by using `RaiseTheExceptionInternalOnly` to raise the `ThreadAbortException` in the `Thread::HandleThreadAbort`. The `Thread::HandleThreadAbort` is always called by native code that has a native catch or (on Windows) ends up calling the `ProcessCLRException`. I have originally made the change to call the `DispatchManagedException` from the `Thread::HandleThreadAbort`, but this issue shows it is problematic. I have verified that the repro provided by @eterekhin in the issue report no longer causes the process to crash with failfast, but reports the funceval as timed out as expected. Close dotnet#118015
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a thread abort issue in function evaluation (funceval) where the process would crash with a failfast error instead of properly timing out. The issue occurred when there were no managed frames between the abortion point and the FuncEvalFrame, such as when invoking static methods whose static constructors hadn't been called yet.
Key changes:
- Unified exception handling by removing conditional compilation around exception dispatch
- Changed from
DispatchManagedExceptiontoRaiseTheExceptionInternalOnlyfor all platforms
jkotas
approved these changes
Aug 4, 2025
This was referenced Aug 4, 2025
|
@janvorli, Thanks a lot for the fix! I confirm the bug is gone :) |
|
@eterekhin thank you for checking! |
radekdoulik
pushed a commit
to radekdoulik/runtime
that referenced
this pull request
Aug 5, 2025
There is a problem with threadabort in funceval in case there is no managed frame on the stack between the abortion point and the `FuncEvalFrame`. That can happen e.g. when invoking a static method via funceval for a type with static constructor that was not invoked yet and takes a long time to complete. The problem is caused by the fact that when EH is called to propagate the ThreadAbortException, it starts at the first managed frame and so it skips the try/catch in the funceval native code. This change fixes it by using `RaiseTheExceptionInternalOnly` to raise the `ThreadAbortException` in the `Thread::HandleThreadAbort`. The `Thread::HandleThreadAbort` is always called by native code that has a native catch or (on Windows) ends up calling the `ProcessCLRException`. I have originally made the change to call the `DispatchManagedException` from the `Thread::HandleThreadAbort`, but this issue shows it is problematic. I have verified that the repro provided by @eterekhin in the issue report no longer causes the process to crash with failfast, but reports the funceval as timed out as expected. Close dotnet#118015
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is a problem with thread abort in funceval in case there is no managed frame on the stack between the abortion point and the
FuncEvalFrame. That can happen e.g. when invoking a static method via funceval for a type with static constructor that was not invoked yet and takes a long time to complete.The problem is caused by the fact that when EH is called to propagate the
ThreadAbortException, it starts at the first managed frame and so it skips the try/catch in the funceval native code.This change fixes it by using
RaiseTheExceptionInternalOnlyto raise theThreadAbortExceptionin theThread::HandleThreadAbort. TheThread::HandleThreadAbortis always called by native code that has a native catch or (on Windows) ends up calling theProcessCLRException.I have originally made the change to call the
DispatchManagedExceptionfrom theThread::HandleThreadAbort, but this issue shows it is problematic.I have verified that the repro provided by @eterekhin in the issue report no longer causes the process to crash with failfast, but reports the funceval as timed out as expected.
Close #118015