Fix GC hole when method return is hijacked for GC suspension by BrzVlad · Pull Request #129714 · dotnet/runtime

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

BrzVlad · 2026-06-22T19:56:24Z

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all.

As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill.

Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via MethodBaseInvoker.InterpretedInvoke_Method -> RuntimeMethodHandle_InvokeMethod -> CallDescrWorkerInternal. Was able to reliably reproduce this by running with DOTNET_HeapVerify=1 with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

Copilot

Pull request overview

This PR adjusts CoreCLR’s thread hijacking during GC suspension so that, on non-x86 targets, the runtime does not hijack a method return when the saved return address doesn’t map to JITted code (e.g., returning into the interpreter), avoiding a GC root hole for return-register values.

Changes:

Add an EECodeInfo validity check (non-x86) in Thread::HijackThread and early-out if the hijacked return address is not JITted code.
On ARM64, strip PAC bits from the return address (via PacStripPtr) before using it for code identity checks.
Add an extern declaration for PacStripPtr in threadsuspend.cpp for ARM64 builds.

jkotas · 2026-06-22T22:11:02Z

Maybe other callsites could run into the same issue.

There should be no other unmanaged callsites of managed code except CallDescrWorker.

dotnet-policy-service · 2026-06-22T22:12:14Z

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

BrzVlad · 2026-06-23T18:25:41Z

/ba-g unrelated build timeouts

Some library test suites running in Interp-JIT mixed configuration displayed a high rate of failure. This turned out to be caused by hijacking the return of a JIT frame that was returning into the interpreter. When the return value is hijacked a new explicit HijackFrame is created, however this frame doesn't produce any roots, it just facilitates reaching the calling frame for which we scan the actual GCInfo. This frame will own and scan the value from the return register from the hijacked frame. The problem arises when the calling method is the interpreter. The interpreter calls compiled methods directly and it has no state of the registers. The first operation that the interpreter does with the return value is to store it on the interpreter stack. However, if the return address is hijacked, we don't enter the interpreter to publish the values to the interpreter stack so the values end up not being scanned at all. As a fix, we disable hijacking if the return address is not jitted code, with the same pattern used in HandleSuspensionForInterruptedThread, which should be signal safe. HijackFrame actually reports some roots from registers on X86, but adding this for all calling convention specifics on other arches seems like overkill. Looking at the nature of this failure, the question arises whether this is an interpreter only fix. After some additional investigation, it turns out that at least reflection based method invocation via `MethodBaseInvoker.InterpretedInvoke_Method` -> `RuntimeMethodHandle_InvokeMethod` -> `CallDescrWorkerInternal`. Was able to reliably reproduce this by running with `DOTNET_HeapVerify=1` with forced interpreted invoke on the following sample https://gist.github.com/BrzVlad/debbb230b75a26f31c1b8b670e6e0924. Maybe other callsites could run into the same issue.

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

CopilotAI review requested due to automatic review settings June 22, 2026 19:56

BrzVlad added the area-GC-coreclr label Jun 22, 2026

dotnet-policy-serviceBot assigned BrzVlad Jun 22, 2026

Copilotstarted reviewing on behalf of BrzVlad June 22, 2026 19:56 View session

CopilotAI reviewed Jun 22, 2026
View reviewed changes

jkotas reviewed Jun 22, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/threadsuspend.cpp

build-analysisBot mentioned this pull request Jun 22, 2026
Intermittent build failure in AfterSourceBuild: "Could not write state file" #76488
Closed

jkotas added area-VM-coreclr and removed area-GC-coreclr labels Jun 22, 2026

build-analysisBot mentioned this pull request Jun 23, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

jkotas suggestion
b1452a4

jkotas approved these changes Jun 23, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 23, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
3 tasks

BrzVlad merged commit b5e2bef into dotnet:mainJun 23, 2026
107 of 110 checks passed

dotnet-maestroBot mentioned this pull request Jun 24, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7344
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 24, 2026

github-actionsBot locked and limited conversation to collaborators Jul 24, 2026

Uh oh!

Conversation

BrzVlad commented Jun 22, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

jkotas commented Jun 22, 2026

Uh oh!

dotnet-policy-serviceBot commented Jun 22, 2026

Uh oh!

BrzVlad commented Jun 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

BrzVlad commented Jun 22, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

jkotas commented Jun 22, 2026

Uh oh!

dotnet-policy-serviceBot commented Jun 22, 2026

Uh oh!

BrzVlad commented Jun 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

BrzVlad commented Jun 22, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

jkotas commented Jun 22, 2026

Uh oh!

dotnet-policy-serviceBot commented Jun 22, 2026

Uh oh!

BrzVlad commented Jun 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

BrzVlad commented Jun 22, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!