JIT: Fix uninitialized gtCallMethHnd for indirect calls causing false recursive tail call detection by AndyAyersMS · Pull Request #127293 · dotnet/runtime

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

AndyAyersMS · 2026-04-22T18:09:30Z

Note

This PR was generated with the assistance of GitHub Copilot.

Fixes#126930

Problem

PR #125211 removed the union between gtCallMethHnd and gtCallAddr in GenTreeCall, making them separate fields. However, gtNewCallNode was not updated to initialize gtCallMethHnd for CT_INDIRECT calls. Since the JIT arena allocator doesn't zero memory in Release builds, gtCallMethHnd contains stale arena data.

When the stale data coincidentally matches the compiled method's handle, gtIsRecursiveCall() falsely returns true for indirect calls. Combined with !call->IsVirtual() being true for CORINFO_VIRTUALCALL_LDVIRTFTN calls (which lack GTF_CALL_VIRT_* flags), fgMorphRecursiveFastTailCallIntoLoop incorrectly transforms the call into a backward jump — creating an infinite allocating loop.

This only manifests non-deterministically depending on arena memory layout, which is why it appears on x64 CI but not on arm64 or in local builds.

Fix

Three surgical changes:

gentree.cpp (gtNewCallNode): Initialize gtCallMethHnd = NO_METHOD_HANDLE for CT_INDIRECT calls — the primary fix that prevents stale data.
compiler.h (gtIsRecursiveCall): Defense-in-depth — return false for CT_INDIRECT calls since indirect calls can never be recursive by definition.
gentree.cpp (gtCloneExprCallHelper): Same initialization for cloned indirect calls to prevent the same issue in clone paths.

… recursive tail call detection PR dotnet#125211 broke the union between gtCallMethHnd and gtCallAddr into separate fields but did not initialize gtCallMethHnd for CT_INDIRECT calls. Since the arena allocator does not zero memory in Release builds, gtCallMethHnd contains stale data that can accidentally match the compiled method's handle, causing gtIsRecursiveCall() to return true. Combined with the CORINFO_VIRTUALCALL_LDVIRTFTN import path (used for generic interface calls in R2R) which creates CT_INDIRECT calls without GTF_CALL_VIRT_* flags, the recursive tail call optimization incorrectly transforms the call into a backward jump, creating an infinite allocating loop. Fix by: 1. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtNewCallNode for CT_INDIRECT 2. Adding a defense-in-depth check in gtIsRecursiveCall to return false for indirect calls 3. Initializing gtCallMethHnd = NO_METHOD_HANDLE in gtCloneExprCallHelper for CT_INDIRECT Fixesdotnet#126930 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-04-22T18:11:50Z

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

Copilot

Pull request overview

This PR fixes a CoreCLR JIT correctness issue introduced when GenTreeCall::gtCallMethHnd was split from the former gtCallAddr union: indirect call nodes (CT_INDIRECT) could leave gtCallMethHnd uninitialized, leading to nondeterministic false “recursive tail call” detection and potential infinite loops/OOMs.

Changes:

Initialize gtCallMethHnd to NO_METHOD_HANDLE for newly created CT_INDIRECT calls.
Initialize gtCallMethHnd to NO_METHOD_HANDLE when cloning CT_INDIRECT calls.
Add a guard in gtIsRecursiveCall(GenTreeCall*) to always return false for CT_INDIRECT calls (defense-in-depth).

Reviewed changes

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

File	Description
`src/coreclr/jit/gentree.cpp`	Ensures indirect call creation/cloning does not leave `gtCallMethHnd` holding stale arena data.
`src/coreclr/jit/compiler.h`	Prevents recursive-call checks from consulting method handles on indirect calls.

AndyAyersMS · 2026-04-24T00:08:44Z

@dotnet/jit-contrib PTAL

Suggest we take this to fix the ci-optional issue and then circle back to add better protection.

Copilot

Pull request overview

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

CopilotAI review requested due to automatic review settings April 22, 2026 18:09

github-actionsBot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 22, 2026

Copilotstarted reviewing on behalf of AndyAyersMS April 22, 2026 18:10 View session

dotnet-policy-serviceBot assigned AndyAyersMS Apr 22, 2026

CopilotAI reviewed Apr 22, 2026
View reviewed changes

SingleAccretion reviewed Apr 22, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/gentree.cpp

CopilotAI mentioned this pull request Apr 23, 2026
Fix race condition: set _canceled before SignalCore in ProcessWaitState #127312
Merged

AndyAyersMS added 2 commits April 23, 2026 11:17

Merge branch 'main' into fix/126930-uninit-gtCallMethHnd
575ed1c

Merge branch 'main' into fix/126930-uninit-gtCallMethHnd
ca4097c

CopilotAI review requested due to automatic review settings April 24, 2026 00:07

Copilotstarted reviewing on behalf of AndyAyersMS April 24, 2026 00:08 View session

CopilotAI reviewed Apr 24, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/gentree.cpp

build-analysisBot mentioned this pull request Apr 24, 2026
Unable to pull image from mcr.microsoft.com #117164
Closed

jakobbotsch approved these changes Apr 24, 2026
View reviewed changes

AndyAyersMS merged commit 5ff2ecf into dotnet:mainApr 24, 2026
137 of 139 checks passed

dotnet-maestroBot mentioned this pull request Apr 25, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#6272
Merged

Youssef1313 mentioned this pull request May 22, 2026
Multiple ASP.NET Core-related test projects hang on .NET 11 Preview 4 linux-arm64 #128490
Closed
1 task

github-actionsBot locked and limited conversation to collaborators May 25, 2026