Fix deadlock when creating threads from ModuleInitializer in a shared library #118928

MichalStrehovsky · 2025-08-20T14:27:06Z

The problem is that the first time we reverse p/invoke into an API in the shared library, we need to do two things: initialize runtime and run module initializers. Running module initializers is done as part of runtime initialization in the shared library case because it was convenient to do it there (in the EXE case, we run them after runtime initialization, right before Main).

The problem with running it as part of the runtime initialization is that the arbitrary user code can deadlock us (see the issues for stack).

This fixes the problem by attaching the newly created thread to the runtime before we do the reverse p/invoke. Since thread is already attached, we don't wait for runtime initialization. Waiting is unnecessary because the runtime needs to be really far along the initialization path if we got to a managed Thread.Start call.

Fixes #118773. Fixes #107699.

Cc @dotnet/ilc-contrib

… library The problem is that the first time we reverse p/invoke into an API in the shared library, we need to do two things: initialize runtime and run module initializers. Running module initializers is done as part of runtime initialization in the shared library case because it was convenient to do it there (in the EXE case, we run them after runtime initialization, right before Main). The problem with running it as part of the runtime initialization is that the arbitrary user code can deadlock us (see the issues for stack). This separates runtime initialization and running module initializers. Doing just that doesn't fix the problem though because the deadlock we saw is part of thread creation. So we'd just deadlock on the module initializer runner. This introduces a new kind of reverse p/invoke enter routine that doesn't wait for module initializers. Instead we wait for module initializers before we are ready to run user code on the thread (and the thread is initialized just enough that ThreadStart can make progress). This also fixes a potential issue in the EXE case where threads created from module initializers could start running before we're finished running module initializers. Instead this introduces a new opportunity for deadlocking :(. I don't actually like this fix. But we need to do something about it because EventSource does exactly this (dotnet#118773). Fixes dotnet#118773. Fixes dotnet#107699.

dotnet-policy-service · 2025-08-20T14:28:16Z

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

Copilot

Pull Request Overview

This PR fixes a deadlock issue that occurs when threads are created from ModuleInitializer methods in shared libraries. The problem was that runtime initialization and module initializer execution were tightly coupled, causing deadlocks when module initializers created threads that needed reverse p/invoke transitions.

Key changes:

Separates runtime initialization from module initializer execution
Introduces a "lite" reverse p/invoke transition that doesn't wait for module initializers
Adds manual synchronization to ensure module initializers complete before user code runs on new threads

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
SharedLibrary.cs	Adds regression test that creates a thread in ModuleInitializer
NativeLibraryStartupMethod.cs	Removes module initializer execution from runtime initialization
CorInfoImpl.cs	Special-cases ThreadEntryPoint to use lite reverse p/invoke transition
Thread.NativeAot.cs	Adds manual wait for module initializers before running user code
Thread.NativeAot.Windows.cs	Documents special compiler handling of ThreadEntryPoint
Thread.NativeAot.Unix.cs	Documents special compiler handling of ThreadEntryPoint
thread.h	Adds EnsureModuleInitializersExecuted method and parameter to existing method
thread.cpp	Implements separated runtime and module initializer logic
StartupCodeHelpers.cs	Adds volatile flag and C-callable wrapper for module initializers
main.cpp	Updates callback registration to handle both runtime and module initialization

src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/Thread.NativeAot.cs

src/coreclr/nativeaot/Runtime/thread.cpp

VSadov · 2025-08-20T22:32:00Z

This also fixes a potential issue in the EXE case where threads created from module initializers could start running before we're finished running module initializers. Instead, this introduces a new opportunity for deadlocking :(.

I think also if a module initializer drops a finalizable object, finalizer thread may run without waiting. That is because we pre-attach the finalizer thread. Perhaps we should not. I do not think it is necessary to pre-attach.

src/coreclr/nativeaot/Runtime/thread.cpp

src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/Thread.NativeAot.cs

VSadov · 2025-08-20T23:58:04Z

I don't actually like this fix. But we need to do something about it because EventSource does exactly this (#118773).

I kind of feel the same. We may yet find some other ways the scenario can get us in trouble. The fix does seem to solve the issue at hand.

src/coreclr/nativeaot/Runtime/thread.cpp

jkotas

LGTM otherwise. Thanks!

Co-authored-by: Jan Kotas <[email protected]>

MichalStrehovsky · 2025-08-22T04:53:57Z