Disable release assert on disallowed thread re-initialization for managed C++ #118827
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR disables a release assert for managed C++ applications that attempt to execute managed code after .NET runtime thread state has been destroyed. The change provides backward compatibility by replacing deterministic failures with intermittent hangs and crashes for mixed-mode binaries.
Key changes:
- Conditionally disables a runtime assert based on whether IJW (It Just Works) mixed-mode binaries have been loaded
- Adds tracking of IJW binary loading state through a global flag
- Provides a new public method to check if any IJW binaries have been loaded
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/coreclr/vm/ceemain.cpp | Conditionally disables assert for thread re-initialization when IJW binaries are present |
| src/coreclr/vm/ceeload.h | Declares new static method to check IJW loading state |
| src/coreclr/vm/ceeload.cpp | Implements IJW tracking logic and exposes check method |
|
Tagging subscribers to this area: @mangod9 |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
Is it not better to deterministically fail rather than indeterminate behavior. If this was "undefined" can we check if there is any workaround available here? |
A thread has just told us "here is the last chance to clean up" and we have destroyed all the state for the thread in the runtime and now it wants to run managed code again. There is no good solution to this. We cannot recover the previous state. We can set up some new state to a degree that the thread can run "simple" managed code, but hard to tell what will happen in all possible scenarios. Also, there will not be another cleanup callback, so the new state will leak and, when the thread truly exits, may become corrupted. (which is probably ok, if the process is terminating). Yes, deterministic fail would be better, if there was no common scenario that triggers this, but now we have discovered one such scenario. I was thinking of maybe forcing a thread that tries to "re-attach" into some kind of "no-GC" mode, but it may just trade some potential issues for others. The mitigation seems unfortunate, but narrowing it just for IJW case (which wants this at process exit) makes it less worrisome. |
This check uncovered a long-standing bug in managed C/C++ compiler and libraries in basic use case. It is not clear whether and when C/C++ team will be able to fix it. |
|
/backport to release/9.0-staging |
|
Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/17044005889 |
needs to be moved to 10-rc1 too? |
Yes... I realized that on the bus in. |
|
/backport to release/10.0-rc1 |
|
Started backporting to release/10.0-rc1: https://github.com/dotnet/runtime/actions/runs/17045414642 |
|
/backport to release/10.0 |
|
Started backporting to release/10.0: https://github.com/dotnet/runtime/actions/runs/17135493496 |
4 participants
This replaces deterministic fails with intermittent hangs and crashes for backward compatibility.
Contributes to #118741