[android] Got a SIGSEGV while executing native code. at System.DateTime.get_Now()

[EgorBo]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1399124&view=logs&j=229f457c-7738-55ec-4101-adaee36685f8
Build error leg or test failing: Build / windows-x64 Debug NativeAOT
Pull request: #127488

Error Message

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

{
  "ErrorMessage": "at System.DateTime.get_Now()",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1399124
Error message validated: [at System.DateTime.get_Now()]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 4/28/2026 11:07:02 AM UTC

Report

Build	Definition	Test	Pull Request
1400017	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127497
1400001	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127493
1399534	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127058
1399977	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127469
1399969	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#126576
1399942	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127503
1399949	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127507
1399929	dotnet/runtime	System.Runtime.InteropServices.Tests.WorkItemExecution	#127505
1399918	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127165
1399885	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127324
1399878	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#125436
1399875	dotnet/runtime	System.Runtime.InteropServices.Tests.WorkItemExecution	#127502
1399843	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#125452
1399840	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127454
1399829	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127499
1399815	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127485
1399727	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#126701
1399731	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#126360
1399604	dotnet/runtime	System.Data.Common.Tests.WorkItemExecution	#127498
1399628	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127438
1399619	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127238
1399622	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127148
1399599	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127498
1399596	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127497
1399567	dotnet/runtime	System.Runtime.InteropServices.Tests.WorkItemExecution	#127267
1399544	dotnet/runtime	System.Runtime.InteropServices.Tests.WorkItemExecution	#126947
1399541	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127464
1399124	dotnet/runtime	System.Runtime.Tests.WorkItemExecution	#127488

Summary

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

[dotnet-policy-service]

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

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[jkotas]

Related to #127225

[dotnet-policy-service]

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

[mangod9]

Here is the analysis:

Investigation Summary

Symptoms

• Platform: Android ARM32 (armeabi-v7a), CoreCLR JIT, Release
• Test: System.Runtime.Tests (and multiple other test suites)
• Error: SIGSEGV (signal 11), SEGV_MAPERR, fault addr 0x0 — null pointer dereference
• Hit count: 10 in 24 hours, blocking multiple PRs
• First failure: April 28, 2026 ~02:00 UTC

Regression Source

PR #127225 — "[android] Enable CoreCLR runtime pack production for
android-arm"

• Author: @simonrozsival
• Merged: April 28, 2026 00:58 UTC — exactly 1 hour before the first failure
• This PR adds a brand new CI leg (android-arm Release AllSubsets_CoreCLR_Smoke) that never existed before
• Every failing build started after the merge

Crash Details (from Android bugreport tombstone)

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 Cause: null pointer dereference

Registers: r0=0 r1=0 r2=0 r3=0

backtrace: #00 pc 00018c00 libm.so (modf+144) ← null ptr deref writing result #1 pc 001a7af9 anonymous:bd319000 (
anonymous:bd319000) ← JIT-compiled managed code

Managed stack (from DOTNET logcat):

at System.DateTime.get_Now() at Microsoft.DotNet.XHarness.TestRunners.Common.LogWriter.InitLogging() at
...ApplicationEntryPoint.InternalRunAsync() at SimpleAndroidTestRunner.Main()

The crash happens during test runner initialization — before any test executes.

Root Cause Analysis

The call chain

DateTime.Now → TimeZoneInfo.GetLocalDateTimeNowTicks() → Math.Truncate(double d) // [Intrinsic] — but NOT intrinsified
on ARM32 → ModF(d, &d) // fallback managed implementation → COMDouble::ModF [FCall] // native: modf(x, intptr) → libm
modf(x, intptr) // CRASH: intptr = NULL (r0 = 0)

Math.Truncate is marked [Intrinsic] and the JIT uses FRINTZ (round toward zero) on ARM64. But FRINTZ only
exists on ARM64 (instrsarm64.h), not ARM32. So on ARM32, Math.Truncate falls back to its managed implementation
which calls the ModF FCall.

Why intptr is NULL

Math.Truncate passes &d — the address of its double parameter — to ModF:

public static unsafe double Truncate(double d)
{
    ModF(d, &d);    // &d = address of parameter on stack
    return d;
}

On ARM32 hard-float ABI (Android), parameter d arrives in VFP register d0, not on the stack. To compute &d, the JIT must spill d to a stack slot first.

Two key paths in lclvars.cpp handle this spilling — but only for soft-float:

Line 660 — marks float params as address-exposed (forces stack home):

if (info.compIsVarArgs || (opts.compUseSoftFP && varTypeIsFloating(varDsc)))
{
    lvaSetVarAddrExposed(...)  // ← SKIPPED on hard-float
}

Line 1000 — prespills float params from registers to stack:

bool preSpill = opts.compUseSoftFP && varTypeIsFloating(varDsc);
// ← false on hard-float, float params NOT prespilled

On soft-float (armel), doubles are passed in integer registers (r0:r1) and these paths ensure they're homed to the
stack. On hard-float (Android arm), doubles are in VFP registers (d0) and these paths are skipped. The JIT relies on
normal address-taken detection to force a stack home — but this may not work correctly when Math.Truncate is inlined
into DateTime.Now, leaving d in a VFP register with no stack slot

[dotnet-policy-service]

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