Uh oh!
There was an error while loading. Please reload this page.
Fix CrstILStubGen/CrstLoaderAllocatorReferences lock level violation - #125675
Merged
Conversation
Contributor
Tagging subscribers to this area: @agocke |
jkotas
reviewed
Mar 17, 2026
Uh oh!
There was an error while loading. Please reload this page.
jkotas
reviewed
Mar 17, 2026
Uh oh!
There was an error while loading. Please reload this page.
CopilotAI
changed the title
[WIP] [DOTNET-125638] Fix Crst lock level violation in CoreCLR runtimeFix CrstILStubGen/CrstLoaderAllocatorReferences lock level violationMar 17, 2026
…fix is sufficient Co-authored-by: jkotas <6668460+jkotas@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates CoreCLR Crst (lock) hierarchy metadata to allow CrstLoaderAllocatorReferences to be taken after CrstILStubGen, and regenerates the derived lock-level map used for debug-time deadlock validation.
Changes:
- Adds
ILStubGento theAcquiredAfterlist forLoaderAllocatorReferencesinCrstTypes.def. - Regenerates
crsttypes_generated.hsoCrstILStubGen’s computed level reflects the updated dependency graph.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/coreclr/inc/CrstTypes.def | Adds ILStubGen as an allowed “acquired after” predecessor for LoaderAllocatorReferences to encode the intended lock ordering. |
src/coreclr/inc/crsttypes_generated.h | Updates the generated debug lock-level map to reflect the new ordering constraints (CrstILStubGen level change). |
This was referenced Mar 18, 2026
jkotas
approved these changes
Mar 18, 2026
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
CreateInteropILStubholdsCrstILStubGenwhile type loading can reachEnsureInstantiation→CrstLoaderAllocatorReferences, but this ordering was undeclared inCrstTypes.def. WithCrstILStubGenat level 14 andCrstLoaderAllocatorReferencesat level 17, attempting to acquire the latter while holding the former triggered a lock-level violation (e.g., during P/Invoke stub generation for types involvingInlineArray<T>generics).Changes
CrstTypes.def— AddILStubGentoAcquiredAfterforLoaderAllocatorReferences, formally declaring thatCrstLoaderAllocatorReferencesmay be acquired whileCrstILStubGenis held.crsttypes_generated.h— Regenerated via CrstTypeTool;CrstILStubGenlevel raised 14 → 18 (must exceedCrstLoaderAllocatorReferencesat 17).Original prompt
fix#125638 issue with these changes
[Chronological Review] 1. User requested investigation of bug https://github.com//issues/125638 - a Crst lock level violation in CoreCLR runtime 2. Read the GitHub issue (#125638) and revert PR (#125664), plus the original triggering PR (#125574) 3. Read issue comments to get the full stack trace from jkotas 4. Read PR #125664 diff to understand the revert (InlineArrays back to fixed buffers) 5. Launched background explore agent to find lock-related code paths 6. In parallel, grepped for CrstILStubGen, CrstLoaderAllocatorReferences, EnsureInstantiation 7. Examined loaderallocator.cpp (EnsureInstantiation, EnsureReference methods) 8. Examined ilstubcache.cpp (GetStubMethodDesc, CreateNewMethodDesc, CreateModuleIndependentSignature) 9. Examined dllimport.cpp (CreateInteropILStub - where CrstILStubGen is held via ListLockHolder) 10. Examined crst.cpp (IsSafeToTake - the lock level violation check logic) 11. Found CrstTypes.def - the configuration file for lock ordering 12. Read lock ordering declarations for ILStubGen and LoaderAllocatorReferences 13. Found Debug_CanTake() implementation - it actually Enter()/Leave() the lock 14. Created plan.md and todos 15. Implemented 3 changes: moved asserts in loaderallocator.cpp, updated CrstTypes.def, regenerated header 16. Built coreclr checked - first attempts had environment issues, clean rebuild succeeded 17. Ran self code review, verified all changes are correct 18. Marked all todos done[Intent Mapping]
[Technical Inventory]
[Code Archaeology]
[Progress Assessment]
[Context Validation]
[Recent Commands Analysis]
.\build.cmd clr.runtime -rc checkedafter clean rebuild1. Conversation Overview: - Primary Objectives: User requested: "please investigate a bug in coreclr runtime system https://github.com//issues/125638 we know it was exposed by an unrelated change that replaced fixed-size buffers with InlineArrays, this PR reverts that change so we can unblock the CI: https://github.com//pull/125664 but we still want to fix the type system bug." - Session Context: Investigated a Crst lock level violation in CoreCLR where `CrstILStubGen` (level 14) was held while trying to acquire `CrstLoaderAllocatorReferences` (level 17). Traced full call chain, identified root cause as (a) `Debug_CanTake()` assert firing before early-return guards and (b) missing lock ordering declaration. Implemented fix across 3 files, built successfully. - User Intent Evolution: Single clear objective throughout - fix the underlying type system/lock ordering bug exposed by PR #125574.- Technical Foundation:
- CoreCLR VM Runtime: C++ codebase at
- Crst Lock Ordering System: Levels defined in
C:\prj\runtime-main2\src\coreclr\vmCrstTypes.def, processed byCrstTypeTool.cs→ generates `crsttypes_gen...Created from Copilot CLI via the copilot delegate command.
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.