Fix exception handling in the prestub worker #111937
Merged
Conversation
This file contains 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 bug in the new exception handling when ThePreStub is called from CallDescrWorkerInternal and the exception is propagated through that. One of such cases is when a managed class is being initialized during JITting and the constructor is in an assembly that's not found. The bug results in skipping all the native frames upto a managed frame that called that native chain that lead to the exception. In the specific case I've mentioned, a lock in the native code is left in locked state. That later leads to a hang. This was case was observed with Roslyn invoking an analyzer where one of the dependencies was missing. The fix is to ensure that when ThePreStub is called by CallDescrWorkerInternal, the exception is not caught in the PreStubWorker. It is left flowing into the native calling code instead. On Windows, we also need to prevent the ProcessCLRException invocation to call into the managed exception handling code.
jkotas
reviewed
Jan 29, 2025
jkotas
reviewed
Jan 29, 2025
jkotas
reviewed
Jan 29, 2025
These two need the same treatment when they end up being called from CallDescrWorkerInternal. Add regression tests for those cases too. These two cases don't result in a visible failure, so the regression tests just exercise the specific code paths.
|
/azp run runtime-coreclr crossgen2 outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This change is not needed, as that function cannot be called via CallDescrWorker.
|
@jkotas can you please take another look? I believe I have addressed all your feedback. |
|
#111937 (comment) does not appear addressed. |
jkotas
reviewed
Feb 4, 2025
jkotas
reviewed
Feb 4, 2025
There was a problem hiding this comment.
Copilot reviewed 2 out of 12 changed files in this pull request and generated 1 comment.
Files not reviewed (10)
- src/coreclr/vm/excep.cpp: Language not supported
- src/coreclr/vm/exceptionhandling.cpp: Language not supported
- src/coreclr/vm/exceptmacros.h: Language not supported
- src/coreclr/vm/prestub.cpp: Language not supported
- src/coreclr/vm/virtualcallstub.cpp: Language not supported
- src/tests/Regressions/coreclr/GitHub_76531/dependencytodelete.csproj: Language not supported
- src/tests/Regressions/coreclr/GitHub_76531/tailcallinvoker.il: Language not supported
- src/tests/Regressions/coreclr/GitHub_76531/tailcallinvoker.ilproj: Language not supported
- src/tests/Regressions/coreclr/GitHub_76531/test76531.csproj: Language not supported
- src/tests/issues.targets: Language not supported
3 tasks
grendello
added a commit
to grendello/runtime
that referenced
this pull request
Feb 10, 2025
* main: (41 commits) Automated bump of chrome version (dotnet#112309) Add `GetDeclaringType` to `PropertyDefinition` and `EventDefinition`. (dotnet#111646) Update the System.ComponentModel.Annotations solution to build in VS (dotnet#112313) JIT: initial support for stack allocating arrays of GC type (dotnet#112250) [main] Update dependencies from dotnet/roslyn (dotnet#112260) Update Xcode casing (dotnet#112307) update the location of assert for REG_ZR check (dotnet#112294) Enable `SA1206`: Keyword ordering (dotnet#112303) Address feedback on dense FrozenDictionary optimization (dotnet#112298) Start regular pri-1 tests runs with native AOT (dotnet#111391) Observe exceptions from _connectionCloseTcs (dotnet#112190) Test failure - SendAsync_RequestVersion20_ResponseVersion20 (dotnet#112232) Fix init race in mono_class_try_get_[shortname]_class. (dotnet#112282) Remove repeated call to DllMain (dotnet#112285) Replace bitvector.h/cpp with ptrArgTP type in gc_unwind_x86.h/inl (dotnet#112268) JIT: Limit 3-opt to 1000 swaps per run (dotnet#112259) [main] Update dependencies from dotnet/icu, dotnet/runtime-assets (dotnet#112120) Update dependencies from https://github.com/dotnet/emsdk build 20250205.3 (dotnet#112223) Fix EventPipe on Android CoreClr. (dotnet#112270) Fix exception handling in the prestub worker (dotnet#111937) ...
mangod9
pushed a commit
that referenced
this pull request
Feb 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 bug in the new exception handling when
ThePreStubis calledfrom
CallDescrWorkerInternaland the exception is propagated throughthat. One of such cases is when a managed class is being initialized
during JITting and the constructor is in an assembly that's not found.
The bug results in skipping all the native frames upto a managed frame
that called that native chain that lead to the exception.
The effect is that some lock holders are skipped and the exception is
not converted to
TypeInitializationException.The fix is to ensure that when
ThePreStubis called byCallDescrWorkerInternal, the exception is not caught in thePreStubWorker. It is left flowing into the native calling code instead.On Windows, we also need to prevent the
ProcessCLRExceptioninvocationto call into the managed exception handling code for the case when the
ProcessCLRExceptionpersonality routine was on one of our asm helpers.Close #112502