Sporadic crash in xzm_main_malloc_zone_init_range_groups when spawning large binaries (macOS 26.3.1)
We're seeing a sporadic crash (~2-3% of spawns) when launching a large Mach-O binary via posix_spawn(). The crash happens inside libsystem_malloc.dylib during __malloc_init, before any application code runs. The process never reaches main().
Environment: macOS 26.3.1 (25D2128), Apple Silicon (ARM64)
Crash signature
BUG IN LIBMALLOC: pointer range initial reservation failed, Abort Cause 3
#0 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups.cold.1
#1 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups
#2 libsystem_malloc.dylib: xzm_main_malloc_zone_create
#3 libsystem_malloc.dylib: __malloc_init
#4 libSystem.B.dylib: libSystem_initializer
#5 dyld: dyld4::Loader::findAndRunAllInitializers
The binary
It's a Chromium component-build test binary (browser_tests):
~1.5 GiB on disk, 5.54 GiB total VA footprint (__TEXT 517 MiB, __LINKEDIT 1.04 GiB, __PAGEZERO 4 GiB)
Links 527 dylibs via @rpath
All images span ~16.4 GiB of VA when loaded
A simple loop that spawns this binary 200 times via posix_spawn() reliably shows 2-5 crashes. Spawning /bin/cat 1000 times produces zero failures.
Investigation
We did extensive analysis to understand the root cause:
ASLR is irrelevant. We disabled ASLR using _POSIX_SPAWN_DISABLE_ASLR (flag 0x0100) and the failure rate is unchanged (~2% with or without). With ASLR disabled, the library addresses are identical across all crashes, confirming the VA layout itself isn't the problem.
Plenty of free VA space is available. We compared the memory layout of crashing processes (from crash reports) with successful ones (via vmmap):
In successful spawns, XZone places its MALLOC zones (SMALL, LARGE, metadata) in the large free regions after the loaded dylibs — for example at 0x784400000 and 0xD32000000, with 13-22 GiB contiguous free gaps available.
In crashing processes, the same free regions exist (the image layout is identical), but xzm_main_malloc_zone_init_range_groups fails to reserve into them.
Based on libmalloc/tests/memory_pressure.c, XZone needs 8 GiB for pointer ranges and 10 GiB for data ranges. The free gaps after the dylibs are far larger than this, yet the reservation sporadically fails.
No workarounds exist. MallocNanoZone=0 has no effect (the crash is before zone configuration). The crash is entirely within system code.
Questions
Is this a known issue in XZone malloc on macOS 26.x?
Is there any environment variable or entitlement that could work around this?
Any guidance on what makes xzm_main_malloc_zone_init_range_groups fail non-deterministically when contiguous VA space is clearly available?
Topic:
App & System Services
SubTopic:
Core OS
2
0
69