Fix iOS arm64 CoreCLR crash from shared MethodDesc::CalliCookie slot by kotlarmilos · Pull Request #127876 · dotnet/runtime

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

kotlarmilos · 2026-05-06T17:09:02Z

Problem

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

The interpreter-to-native call path stores a helper that's set up for the method's own signature
The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes#127869 #127863 #127867

PR dotnet#127016 added a new writer to MethodDescCodeData::CalliCookie in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a per-calli-signature CallStubHeader* on the P/Invoke target MethodDesc. The same slot already has writers/readers that key on different signatures (UpdateCallStubForMethod for InvokeManagedMethod / InvokeDelegateInvokeMethod, and the FEATURE_PORTABLE_ENTRYPOINTS INTOP_CALLI path / wasm/helpers.cpp using MetaSig(targetMethod)). First-writer-wins meant later readers dispatched through an incompatible Routines array and CallJittedMethodRetI8 jumped to a PCODE 0 entry. On iOS arm64 device this surfaces as EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE at 0x0 → CODESIGNING / Invalid Page → SIGKILL (CS_KILL on app-bundle processes). Drop the pContextMD->{Set,Get}CalliCookie reads/writes in GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-dotnet#127016 behavior. pContextMD is still passed so Swift calling-convention detection is preserved. Fixesdotnet#127869 (and the duplicates dotnet#127863 / dotnet#127867). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-06T17:10:38Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkotas · 2026-05-06T17:49:20Z

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

 // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
// calling the target via managed calling convention. The stub we are about
// to generate calls the target via unmanaged calling convention.

CopilotAI review requested due to automatic review settings May 6, 2026 17:09

Copilotstarted reviewing on behalf of kotlarmilos May 6, 2026 17:09 View session

github-actionsBot added the area-CodeGen-Interpreter-coreclr label May 6, 2026

dotnet-policy-serviceBot assigned kotlarmilos May 6, 2026

kotlarmilos marked this pull request as ready for review May 6, 2026 17:14

kotlarmilos requested review from AaronAstle, AaronRobinsonMSFT, jkotas and radekdoulik May 6, 2026 17:14

kotlarmilos added this to the 11.0.0 milestone May 6, 2026

Trim code comment
2a567d2
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

kotlarmilos mentioned this pull request May 6, 2026
[iOS][interp] Null calli target in MethodBaseInvoker.InvokeWithOneArg #127869
Closed

jkotas approved these changes May 6, 2026
View reviewed changes

kotlarmilos commented May 6, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/jitinterface.cpp Outdated

Update src/coreclr/vm/jitinterface.cpp
4581fd0

kotlarmilos enabled auto-merge (squash) May 6, 2026 18:28

kotlarmilos merged commit 5566dcc into dotnet:mainMay 7, 2026
109 checks passed

kotlarmilos mentioned this pull request May 7, 2026
CI failure on iOS: test process was killed because of OS_REASON_CODESIGNING #127867
Closed

dotnet-maestroBot mentioned this pull request May 8, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#6525
Closed

kotlarmilos mentioned this pull request May 12, 2026
Interpreter SIGSEGV in latest maestro bump #128064
Closed

dotnet-maestroBot mentioned this pull request May 12, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#6573
Merged

This was referenced Jun 2, 2026
[dkurepa/Testing] Source code updates from maestro-auth-test/runtime maestro-auth-test/dotnet#246
Closed
[dkurepa/Testing] Source code updates from maestro-auth-test/runtime maestro-auth-test/dotnet#247
Closed

kotlarmilos mentioned this pull request Jun 4, 2026
Stackoverflow at startup with CoreCLR on ios simulator x64 #128898
Closed

github-actionsBot locked and limited conversation to collaborators Jun 11, 2026