Fix VSD cache lock ordering during unload

[adamperlin]

Summary

• release the virtual stub dispatch cache lock before deleting loader heaps that acquire the executable allocator lock
• add a collectible AssemblyLoadContext regression test that grows the VSD cache entry heap and exercises the lock-order failure

Fixes #132982

Testing

• build.cmd clr -rc checked
• src\tests\build.cmd -Test Regressions\coreclr\GitHub_132982\test132982.csproj x64 checked -Priority 1
• confirmed the regression test triggers the CrstStubDispatchCache / CrstExecutableAllocatorLock level violation without the fix and passes with the fix

Note

This pull request description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

🔵 Needs a closer look

It changes low-level CoreCLR VM locking behavior during unload/heap teardown, which merits final human review despite the targeted fix and added regression test.

Pull request overview

Fixes a CoreCLR VM lock ordering problem during collectible AssemblyLoadContext unload by ensuring the VSD cache lock is not held while freeing loader heaps that may take the executable allocator lock, and adds a regression test to exercise the scenario.

Changes:

• Restrict the lifetime of the VSD resolve-cache write lock in VirtualCallStubManager::~VirtualCallStubManager() so it’s released before heap teardown.
• Add a collectible-ALC regression test that grows the VSD cache entry heap and forces unload/GC to validate the lock ordering does not assert.
• Add the corresponding test project configuration under the CoreCLR regressions suite.

File summaries

File	Description
src/coreclr/vm/virtualcallstub.cpp	Scopes the resolve-cache lock to the unlink loop so it’s released before deleting loader heaps.
src/tests/Regressions/coreclr/GitHub_132982/test132982.cs	New xUnit regression test that loads the assembly into a collectible ALC, exercises VSD cache growth, and forces unload/GC.
src/tests/Regressions/coreclr/GitHub_132982/test132982.csproj	New test project wiring (priority, isolation/unloadability flags, and compilation inputs).

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The new regression test project needs RequiresProcessIsolation to match UnloadabilityIncompatible, and the test should assert it runs in the intended collectible AssemblyLoadContext to keep coverage reliable.

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/tests/Regressions/coreclr/GitHub_132982/test132982.cs:162

• To make the regression test more robust, assert that the reflection-loaded assembly actually ended up in the collectible AssemblyLoadContext you created, and fail with a clear error if Dispatcher.Run can’t be found. Otherwise, a future resolution change could accidentally run Dispatcher.Run from the default context and the test would no longer cover the intended unload path.
  src/tests/Regressions/coreclr/GitHub_132982/test132982.csproj:8
• The project sets UnloadabilityIncompatible, which (per docs/workflow/testing/coreclr/requiresprocessisolation.md) requires RequiresProcessIsolation=true so the per-process compatibility skip can work when tests are merged into a shared runner. Without it, the test may still run under RunInUnloadableContext legs and behave unpredictably.

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[jkotas]

Thanks