[release/10.0] Fix PerfMap crash when Enable IPC command is sent early in startup#124208
Merged
steveisok merged 2 commits intodotnet:release/10.0from Feb 11, 2026
Merged
Conversation
Contributor
|
Tagging subscribers to this area: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
Backports fixes to CoreCLR startup/diagnostics so an early DiagnosticServer IPC EnablePerfMap command (e.g., during PauseForDiagnosticsMonitor) no longer crashes the runtime by invoking PerfMap “send existing” logic before the AppDomain / EEJitManager are initialized.
Changes:
- Move
PerfMap::Initialize()earlier inEEStartupHelper()so PerfMap infrastructure is ready beforeDiagnosticServerAdapter::Initialize()starts listening for IPC. - Add a
PerfMapreadiness flag to gatesendExistingbehavior until startup dependencies are initialized. - Signal readiness (
PerfMap::SignalDependenciesReady()) immediately afterExecutionManager::Init().
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/coreclr/vm/perfmap.h |
Adds a new volatile readiness flag and a public signal API to indicate when sendExisting can safely run. |
src/coreclr/vm/perfmap.cpp |
Implements the readiness flag, skips sendExisting enumeration if dependencies aren’t ready, and adds SignalDependenciesReady(). |
src/coreclr/vm/ceemain.cpp |
Reorders PerfMap initialization ahead of DiagnosticServer startup and signals readiness after ExecutionManager::Init(). |
jkotas
approved these changes
Feb 10, 2026
noahfalk
approved these changes
Feb 10, 2026
Member
Author
|
/ba-g "Known infrastructure issue" |
hoyosjs
approved these changes
Feb 10, 2026
Member
|
/ba-g known pkg_resources issue |
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
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.
Manual backport of #123226 and #124055 to release/10.0
Customer Impact
The DiagnosticServer allows profilers to enable PerfMap early in start-up, even before PerfMap is initialized and dependencies are ready, inducing a crash. Enabling PerfMap this early in start-up was not tested until user_events support was added in .NET 10, where One-Collect's record-trace aggressively enables PerfMaps as soon as it connects to a .NET Process so it can resolve JIT'd code. As .NET user_events + record-trace gains more users, this crash will likely be observed more frequently.
With the changes in the two PRs, the runtime is resilient to early PerfMap::Enable commands received by the DiagnosticServer.
DiagnosticServer initialization will still be early in start-up, PerfMap initialization is just bumped right before it.
Regression
Testing
I validated on a wsl2 instance, pausing the startup logic with DOTNET_DefaultDiagnosticPortSuspend=1 and kicking off a separate app invoking DiagnosticClient.EnablePerfMap. Before the change, it would sigsegv and crash.
After the changes, its resilient and doesn't crash.
Risk
Low. PerfMap initialization doesn't depend on the logic between its former and proposed location. The logic to handle early IPC PerfMap Enable commands makes the problematic logic a no-op until the dependencies are ready.