iOS 26 EXC_BREAKPOINT in libmalloc _xzm_xzone_malloc_freelist_outlined during NSData base64 encoding
We are seeing a low-volume but persistent crash on iOS 26 that surfaces inside Foundation's base64 encoder, and we would like to see if and how we could prevent that crash
2026-08-14_10-47-14.9181_-0500-5b74aa117551b30ab7696e1d90c129b97ab1e42f.crash
- (nonnull NSString *)pnd_UTF8Base64 {
NSData *encodedData = [self dataUsingEncoding:NSUTF8StringEncoding];
if (encodedData == nil || encodedData.length == 0) {
return @"";
}
NSData *safeData = [NSData dataWithBytes:encodedData.bytes length:encodedData.length];
return [safeData base64EncodedStringWithOptions:0];
}
Questions:
Is our reading correct that _xzm_xzone_malloc_freelist_outlined indicates the freelist was ALREADY corrupted before this allocation (double-free / use-after-free / buffer overflow somewhere else), and that this base64 malloc is merely the first allocation to detect it (a 'canary'), not the cause?
Did the iOS 26 xzone allocator add/strengthen freelist integrity checks such that latent corruption that previously went unnoticed now traps here?
What is the recommended way to pin down the real corruptor in a shipping app where this reproduces only occasionally on end-user devices (MallocStackLogging, Guard Malloc / libgmalloc, MallocScribble, Address Sanitizer, MallocNanoZone settings)? Are any of these usable/meaningful against the xzone allocator?
Is there any process-level or per-allocation API to validate heap integrity that is safe on the xzone allocator (e.g. malloc_zone_check behavior on iOS 26)?
Any guidance on interpreting this signature and isolating the root cause would be appreciated. Thanks.
1
0
286