Fix P/Invoke IL stub race in DoPrestub by AaronRobinsonMSFT · Pull Request #124579 · dotnet/runtime

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AaronRobinsonMSFT · 2026-02-19T00:23:47Z

Summary

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method.

Root Cause

PR #117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the ILStubCache lookup. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub.

Fix

Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication.
In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc.

Fixes#124530

Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. PR dotnet#117901 made IsSharedStubScenario return false for forward P/Invokes, which disabled the cache. Multiple threads could then each create their own DynamicMethodDesc and JIT it, producing different PCODE values that violated the assert in DoPrestub. The fix: - Remove the forward P/Invoke exclusion from IsSharedStubScenario so these stubs use the ILStubCache for de-duplication. - In CreateHashBlob, create a minimal hash blob containing just the target MethodDesc pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same DynamicMethodDesc. Fixesdotnet#124530 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-02-19T00:25:46Z

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR fixes a race condition in P/Invoke IL stub generation that was introduced by PR #117901. The root cause was that forward P/Invoke stubs (non-CALLI, non-vararg) were excluded from IsSharedStubScenario, disabling the ILStubCache lookup/insert mechanism. This allowed multiple threads to independently create and JIT duplicate IL stubs for the same target method, resulting in different PCODE values and violating the assert in DoPrestub.

Changes:

Re-enables ILStubCache usage for forward P/Invoke stubs by removing their exclusion from IsSharedStubScenario
Creates minimal hash blobs keyed by target MethodDesc pointer for forward P/Invoke stubs to ensure proper cache de-duplication
Updates comments to reflect the new caching behavior

jkoritzinsky · 2026-02-19T00:42:09Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

jtschuster

LGTM, thank you!

AaronRobinsonMSFT · 2026-02-19T01:09:53Z

Could we store the DynamicMethodDesc on the PInvokeMethodDesc directly instead of going through the cache if we always have a 1:1 relationship here?

I think we could, but I really dislike the idea of having multiple places for this sort of data. Instead of hiding it on the PInvokeMethodDesc for this one instance, I would prefer to fix the entire MethodDesc heirarchy and make it less bespoke. Unless there is a compelling reason to add it there, especially since it is a single lookup cost, I'm inclined to leave it as-is.

jkoritzinsky · 2026-02-19T04:25:04Z

Yeah this can wait until we do a greater refactoring of the MethodDesc hierarchy if that's the preference.

jkotas · 2026-02-19T04:41:00Z

refactoring of the MethodDesc hierarchy

There should not be a DynamicMethodDesc for these in the first place. It can be all transient IL.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

… clarifying comments on thread safety during JIT operations

…ed thread safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

…d safety

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

## Summary Re-enable ILStubCache lookup/insert for forward P/Invoke stubs to prevent racing threads from independently creating and JIT-ing duplicate IL stubs for the same target method. ## Root Cause PR dotnet#117901 made `IsSharedStubScenario` return `false` for forward P/Invokes, which disabled the `ILStubCache` lookup. Multiple threads could then each create their own `DynamicMethodDesc` and JIT it, producing different `PCODE` values that violated the assert in `DoPrestub`. ## Fix - Remove the forward P/Invoke exclusion from `IsSharedStubScenario` so these stubs use the `ILStubCache` for de-duplication. - In `CreateHashBlob`, create a minimal hash blob containing just the target `MethodDesc` pointer for forward P/Invoke stubs, so different P/Invoke methods get distinct cache entries while racing threads for the same method converge on the same `DynamicMethodDesc`. Fixesdotnet#124530 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

CopilotAI review requested due to automatic review settings February 19, 2026 00:23

github-actionsBot added the area-VM-coreclr label Feb 19, 2026

dotnet-policy-serviceBot assigned AaronRobinsonMSFT Feb 19, 2026

github-project-automationBot added this to AppModel Feb 19, 2026

AaronRobinsonMSFT requested review from jkotas and jtschuster February 19, 2026 00:24

Copilotstarted reviewing on behalf of AaronRobinsonMSFT February 19, 2026 00:24 View session

AaronRobinsonMSFT added area-Interop-coreclr and removed area-VM-coreclr labels Feb 19, 2026

AaronRobinsonMSFT added this to the 11.0.0 milestone Feb 19, 2026

CopilotAI reviewed Feb 19, 2026
View reviewed changes

jtschuster approved these changes Feb 19, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp
Comment threadsrc/coreclr/vm/dllimport.cpp

Feedback.
4a8c745

This was referenced Feb 19, 2026
Test failure: baseservices/exceptions/stackoverflow/stackoverflowtester/stackoverflowtester.cmd #110173
Open
[android][clr] No peer certificates when executing System.Net.Http.Functional.Tests on Android emulator #124526
Closed

build-analysisBot mentioned this pull request Feb 19, 2026
[Android][CoreCLR] System.Security.Cryptography.Tests killed by lowmemorykiller #118603
Open

Merge branch 'main' into fix-pinvoke-stub-race
612186a

CopilotAI review requested due to automatic review settings February 19, 2026 14:55

Copilotstarted reviewing on behalf of AaronRobinsonMSFT February 19, 2026 14:56 View session

CopilotAI reviewed Feb 19, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp Outdated

jkotas reviewed Feb 19, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp Outdated

jkotas approved these changes Feb 19, 2026
View reviewed changes

AaronRobinsonMSFT added 2 commits February 19, 2026 13:07

Merge remote-tracking branch 'upstream/main' into fix-pinvoke-stub-race
ab6b983

Enhance P/Invoke stub handling by ensuring unique hash blob sizes and…
95d8981
… clarifying comments on thread safety during JIT operations

Update CrstType definitions and adjust CrstILStubGen level for improv…
12f8f2f
…ed thread safety

CopilotAI review requested due to automatic review settings February 20, 2026 00:33

Copilotstarted reviewing on behalf of AaronRobinsonMSFT February 20, 2026 00:33 View session

CopilotAI reviewed Feb 20, 2026
View reviewed changes

build-analysisBot mentioned this pull request Feb 20, 2026
System.IO.Tests.Directory_Create_Tests.FileSystemWatcher_Directory_Create_InNestedDirectory fails with "Created event did not occur as expected" #103630
Closed

AaronRobinsonMSFT added 2 commits February 19, 2026 19:03

Update CrstILStubGen dependencies and adjust level for improved threa…
fa1c8d7
…d safety

Merge branch 'main' into fix-pinvoke-stub-race
2df0aa3

CopilotAI review requested due to automatic review settings February 20, 2026 15:21

Copilotstarted reviewing on behalf of AaronRobinsonMSFT February 20, 2026 15:22 View session

CopilotAI reviewed Feb 20, 2026
View reviewed changes

AaronRobinsonMSFT merged commit 503a82e into dotnet:mainFeb 20, 2026
107 of 109 checks passed

AaronRobinsonMSFT deleted the fix-pinvoke-stub-race branch February 20, 2026 18:34

github-project-automationBot moved this to Done in AppModel Feb 20, 2026

This was referenced Feb 21, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#5026
Closed
[main] Source code updates from dotnet/runtime dotnet/dotnet#5050
Merged

github-actionsBot locked and limited conversation to collaborators Mar 23, 2026