[linux-arm32] Crash caused by misaligned access under genReportAsyncDebugInfo

[rzikm]

Seeing this across all System.Net tests for last couple of weeks, even after copilot analysis I can't find any existing issues, so here it is:

Environment

• Queue: azurelinux.3.arm64.open with Docker image mcr.microsoft.com/dotnet-buildtools/prereqs:debian-13-helix-arm32v7
• Architecture: ARM32 (armv7) running on ARM64 host via Docker
• Branch: refs/heads/main
• Build: 1291383
• Helix Job: 1e1717e0-bb28-49fe-95f2-cbfb05aafe11
• Workitems: System.Net.Requests.Tests, System.Net.Security.Tests (at least)
• Product version: 11.0.0

Crash Details

• Signal: 7 (SIGBUS — unaligned memory access)
• Exit code: 135
• Crashing thread: 0x2e
• Phase: During test execution (OuterLoop tests)

Multiple test suites in the same Helix job crashed with the identical pattern. At least two different test methods were affected:

• HttpWebRequestTest.ReadWriteTimeout_CancelsResponse(Boolean) (System.Net.Requests.Tests, thread 0x2e)
• CertificateValidationRemoteServer.DefaultConnect_EndToEnd_Ok(String) (System.Net.Security.Tests, thread 0x2d)

Both methods were being invoked through the interpreter (InterpretedInvoke_Method), not JIT-compiled code.

Console logs

• System.Net.Requests.Tests: https://helixr18s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-1e1717e0bb2849fe95/System.Net.Requests.Tests/1/console.a0b33339.log?helixlogtype=result
• System.Net.Security.Tests: https://helixr18s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-1e1717e0bb2849fe95/System.Net.Security.Tests/1/console.17fb1494.log?helixlogtype=result

Managed Stack Trace (from dotnet-dump)

OS Thread Id: 0x2e (crashed)
[PrestubMethodFrame: e8766cf8] System.Net.Tests.HttpWebRequestTest.ReadWriteTimeout_CancelsResponse(Boolean)
System.Net.Tests.HttpWebRequestTest.ReadWriteTimeout_CancelsResponse(Boolean)
[InlinedCallFrame: e8766fc8]
System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(System.Object, IntPtr*)
System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(...)
System.Reflection.MethodBaseInvoker.InvokeWithOneArg(...)
System.Reflection.RuntimeMethodInfo.Invoke(...)
System.Reflection.MethodBase.Invoke(System.Object, System.Object[])
Xunit.Sdk.TestInvoker`1.CallTestMethod(System.Object)
  ... (xunit test runner / thread pool frames)

Native-level analysis (lldb)

Loading the System.Net.Security.Tests core dump in lldb on ARM32 confirmed:

• Thread CoreFx hardcodes paths in the Native scripts. #9 (tid 45): stop reason = signal SIGBUS at PC = 0x00000072

Register dump at crash:

r0-r7  = 0x00000000  (all zeroed)
r8     = 0x00000032
r9     = 0xe8569b0c
r10-r12 = 0x00000000
sp     = 0x00000000  ← stack pointer is NULL
lr     = 0x00000072  ← link register (return address)
pc     = 0x00000072  ← program counter (faulting instruction)
cpsr   = 0x0000009c

Key observations:

• SP is NULL: The stack pointer is 0x00000000, so the thread's entire stack context is gone. lldb cannot unwind beyond frame #0.
• Nearly all registers zeroed: r0–r7, r10–r12 are all zero. This is not consistent with a normal unaligned-access SIGBUS, where you'd expect valid register values with one holding the misaligned address.
• PC = LR = 0x00000072: Both point to the same invalid address in the unmapped zero page.
• The zeroed register state suggests this is not a simple alignment bug — the thread's register context was corrupted or never properly initialized before the method dispatch. This looks more like a corrupted method descriptor or prestub table entry that caused the runtime to load an invalid context and branch to 0x72.
• The identical PC value (0x00000072) across both crashes suggests a deterministic bug.

Notes

• The console logs' stack traces were completely unsymbolized (?? at ??:0:0 for all frames). The crash report JSON and dotnet-dump (run in an ARM32 QEMU container) were needed to obtain the managed stacks.
• The PrestubMethodFrame at the top with IP 0x00000072 indicates the crash happened during interpreter method invocation — the runtime was trying to call the interpreted method but jumped to an invalid address instead.
• Both crashes have the identical call chain: PrestubMethodFrame → test method → [InlinedCallFrame] → InterpretedInvoke_Method → InvokeDirectByRefWithFewArgs → xunit runner. The only difference is the test method name.
• This does not appear to be test-specific — the crash is in the interpreter/runtime layer, not in the test logic itself. Any test method invoked via the interpreter on ARM32 could potentially hit this bug.

Possibly Related

• [ARM][ARM64] Problems with empty struct passing #104369 — ARM32 SIGBUS in VolatileLoad<long long> / FieldDesc::GetInstanceField (different code path but same signal/architecture)

Known Issue Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

[jkotas]

Looked at this one:

System.Net.Requests.Tests: https://helixr18s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-1e1717e0bb2849fe95/System.Net.Requests.Tests/1/console.a0b33339.log?helixlogtype=result

runfo get-helix-payload -j 1e1717e0-bb28-49fe-95f2-cbfb05aafe11 -w System.Net.Requests.Tests -o c:\helix_payload

It is crashing in the JIT at:

# Child-SP RetAddr      Call Site
00 e87660f8 ee394077     libclrjit!emitLocation::CodeOffset+0x8 [/__w/1/s/src/coreclr/jit/emit.cpp @ 61] 
01 e8766118 ee39397f     libclrjit!CodeGen::genReportAsyncDebugInfo+0x5f [/__w/1/s/src/coreclr/jit/codegencommon.cpp @ 15732480] 
02 e8766140 ee3986b5     libclrjit!CodeGen::genEmitUnwindDebugGCandEH+0x2b [/__w/1/s/src/coreclr/jit/codegencommon.cpp @ 2252] 
03 e8766150 ee459383     libclrjit!CodeGenPhase::DoPhase+0x19 [/__w/1/s/src/coreclr/jit/codegen.h @ 1660] 
04 e8766158 ee393519     libclrjit!Phase::Run+0x17 [/__w/1/s/src/coreclr/jit/phase.cpp @ 61] 
05 (Inline) --------     libclrjit!DoPhase+0x21 [/__w/1/s/src/coreclr/jit/codegen.h @ 15732480] 
06 e8766168 ee39da3f     libclrjit!CodeGen::genGenerateCode+0x95 [/__w/1/s/src/coreclr/jit/jit.h @ 1812] 
07 e87661a0 ee39e96f     libclrjit!Compiler::compCompile+0xe77 [/__w/1/s/src/coreclr/jit/compiler.cpp @ 5046] 
08 (Inline) --------     libclrjit!Compiler::compIsForInlining+0x1 [/__w/1/s/src/coreclr/jit/compiler.hpp @ 4035] 
09 e8766680 ee39e33d     libclrjit!Compiler::compCompileHelper+0x33f [/__w/1/s/src/coreclr/inc/corjit.h @ 7035] 
0a (Inline) --------     libclrjit!Compiler::compIsForInlining+0x1 [/__w/1/s/src/coreclr/jit/compiler.hpp @ 4035] 
0b (Inline) --------     libclrjit!Compiler::compCompileAfterInit::$_1::operator()+0x1 [/__w/1/s/src/coreclr/inc/corjit.h @ 6204] 
0c e87666d8 ee39f22f     libclrjit!Compiler::compCompileAfterInit+0x1cd [/__w/1/s/src/coreclr/inc/corjit.h @ 6216] 
0d (Inline) --------     libclrjit!jitNativeCode::$_0::operator()::{lambda()#1}::operator()+0x1 [/__w/1/s/src/coreclr/jit/compiler.cpp @ 7675] 
0e (Inline) --------     libclrjit!jitNativeCode::$_0::operator()+0xb1 [/__w/1/s/src/coreclr/inc/corjit.h @ 7695] 
0f e8766718 ee3a1e05     libclrjit!jitNativeCode+0xf7 [/__w/1/s/src/coreclr/inc/corjit.h @ 7697] 
10 e87667b0 f7200e1b     libclrjit!CILJit::compileMethod+0x5d [/__w/1/s/src/coreclr/jit/ee_il_dll.cpp @ 305] 

Instruction:

libclrjit!emitLocation::CodeOffset+0x8:
ee3a436c e9d08000 ldrd        r8,r0,[r0]              00e27d91=0000000000e27d10

[dotnet-policy-service]

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

[jkotas]

@jakobbotsch Looks like a misaligned access under genReportAsyncDebugInfo