EXC_BAD_ACCESS in MapboxCoreMaps render path (MetalView.draw ← updateFromDisplayLink) on 11.27.0 / iPhone 17 / iOS 18.6.2

Environment

• Xcode version: 26.4.1 (17E202)
• iOS version: 18.6.2 (22G100)
• Devices affected: iPhone 17,1 (A18, arm64e) — 1 device, 2 occurrences
• Maps SDK Version: 11.27.0 (mapbox-core-maps-ios 11.27.0, MapboxCommon 24.27.0, via SPM)

Observed behavior and steps to reproduce

Two EXC_BAD_ACCESS crashes from one TestFlight user on 2026-07-31, both inside the MapboxCoreMaps render path reached from MapView.updateFromDisplayLink → MTKView.draw → MetalView.draw(_:).

Both land at the identical binary offset MapboxCoreMaps + 7107576 (framework UUID cc16ad1c-af73-3b18-b2bf-96bda5964801), which suggests one specific code site rather than general memory corruption.

Occurrence 1 — EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000068
VM Region Info: 0x68 is not in any region — i.e. a null dereference at a +0x68 field offset.

Occurrence 2 — EXC_BAD_ACCESS (SIGSEGV) at 0xa76bc05dde5b7930 -> 0x0000405dde5b7930, flagged by the OS as a possible pointer authentication failure (arm64e).

Stack (identical in both):

Thread 0 Crashed:
0   MapboxCoreMaps                	0x00000001063333f8 0x105c6c000 + 7107576
1   MapboxCoreMaps                	0x00000001062e5a38 0x105c6c000 + 6789688
2   MapboxCoreMaps                	0x00000001062f9eac 0x105c6c000 + 6872748
3   MapboxCoreMaps                	0x0000000105eda600 0x105c6c000 + 2549248
4   MapboxCoreMaps                	0x0000000105ed2438 0x105c6c000 + 2516024
5   MyApp                         	0x0000000104ebd5f0 MetalView.draw(_:) + 4 (MetalView.swift:75)
6   MyApp                         	0x0000000104ebd5f0 @objc MetalView.draw(_:) + 140
7   MetalKit                      	0x0000000227d38cf0 -[MTKView draw] + 132 (MTKView.m:1371)
8   MyApp                         	0x0000000104eab744 MapView.updateFromDisplayLink(displayLink:) + 2260 (MapView.swift:741)
9   MyApp                         	0x0000000104eabf30 closure #1 in MapView.didMoveToWindow() + 68 (MapView.swift:783)
10  MyApp                         	0x0000000104ea12b0 ForwardingDisplayLinkTarget.update(with:) + 8 (ForwardingDispalyLinkTarget.swift:33)
11  MyApp                         	0x0000000104ea12b0 @objc ForwardingDisplayLinkTarget.update(with:) + 52
12  QuartzCore                    	0x00000001971351d0 CA::Display::DisplayLinkItem::dispatch_(...)
13  QuartzCore                    	0x0000000197134dc8 CA::Display::DisplayLink::dispatch_items(...)
14  QuartzCore                    	0x0000000197135364 CA::Display::DisplayLink::dispatch_deferred_display_links(...)
15  UIKitCore                     	0x0000000197ea5404 _UIUpdateSequenceRun + 84

(Frames 5, 8, 9, 10 are SDK sources compiled into our binary via SPM.)

Steps to reproduce — not reliably reproducible. The user's own note on occurrence 1 was "Size and bag limit page opened then closed", which in our app is an SFSafariViewController presented as a SwiftUI .sheet over a continuously-rendering MapView (wrapped in a UIViewRepresentable). The suspected sequence is: full-screen sheet presented over the map → dismissed → crash on a display-link frame during or shortly after the transition back. We do not pause the display link while the sheet is presented — the map keeps rendering underneath it the whole time.

Occurrence 2 has no note. That device was low on storage at the time (2.4 GB free of 128 GB), in case resource pressure is relevant to allocation at this site.

We could not reproduce in the Simulator, which is expected given one occurrence is an arm64e PAC failure and the Simulator's Metal path differs.

Expected behavior

A display-link frame delivered while (or just after) a modal view controller is presented over the map should not dereference a null or unauthenticated pointer inside the renderer. Either the render should be safe in that state, or the SDK should skip/refuse the frame.

Notes / preliminary analysis

• The two exception signatures at the same instruction are informative: a null +0x68 dereference in one case and a PAC failure in the other is more consistent with a stale/freed object pointer being dispatched through than with a simple uninitialised field.
• At crash time all MapboxCommon worker threads were idle in pthread_cond_wait — thread 0 was the only thread in Mapbox code, which argues against a straightforward race with a concurrent SDK worker.
• We do not use terrain — no terrain/DEM API is called anywhere in the app — so this is not the terrain_renderer variant in #1177.
• We are on the newest stable release (11.27.0), so there is no upgrade available to us as a mitigation.

Questions

1. Can you map offset +7107576 in 11.27.0 to a source location? That would show whether this shares a root cause with the texture_resource.mm / replaceTexture variant reported in #2195.
2. Is rendering during a modal presentation/dismissal transition a known-unsafe state? If pausing the display link while a sheet covers the map is the recommended mitigation, we'll do that — but we'd rather not paper over an SDK object-lifetime bug if the fix belongs upstream.
3. Is anything at this site expected to change in 11.28.0?

Additional links and references

Possibly related, though all on older SDK versions and with partly differing stacks: #2195, #1637, #1177.

Happy to attach the full .ips crash reports and to test a pre-release build on the affected device.

Start with MetalView.swift:75 and the MapView display-link entry points at MapView.swift:741 and 783, then investigate the 11.27.0 binary offset +7107576. Compare the findings with issues #2195, #1637, and #1177, using the full .ips reports if available. Done means identifying the source location and determining whether modal transitions require a rendering mitigation or an SDK fix.