mapbox
Crash in mapbox::common::CleanupManager::cleanup()
Environment
- Xcode version: 15.3
- iOS version: 17.5
- Devices affected: iPhone OS 17.5 (21F5058e)
- Maps SDK Version: V11.3.0
Observed behavior and steps to reproduce
Run mapbox map and dismiss/display the map multiple times over 30 minutes using same SwiftUI view.
Observed: crash logfile from device Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[app<AppName>:10815] failed to terminate gracefully after 5.0s ProcessVisibility: Unknown ProcessState: Running WatchdogEvent: process-exit WatchdogVisibility: Foreground WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 18.700 (user 14.430, system 4.270), 61% CPU", "Elapsed application CPU time (seconds): 5.393, 17% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread: 0
Kernel Triage: VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x1d3c651cc __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x1e7a126e4 _pthread_cond_wait + 1228
2 libc++.1.dylib 0x19b2a5504 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3 libc++.1.dylib 0x19b2a8ea4 std::__1::__assoc_sub_state::__sub_wait(std::__1::unique_lockstd::__1::mutex&) + 56
4 libc++.1.dylib 0x19b2a8df4 std::__1::__assoc_sub_state::copy() + 56
5 libc++.1.dylib 0x19b2a9198 std::__1::future
Expected behavior
No crash in MapboxCommon mapbox::common::CleanupManager::cleanup()
Notes / preliminary analysis
Device CPU is already loaded at ~50% by the whole app operation.
Additional links and references
The app makes use of multiple
- PointAnnotation (SymbolLayer), CircleAnnotation (CircleLayer), PolylineAnnotation (FillLayer) with Geojson sources
- Layer clustering
- queryRenderedFeatures
Hi @jumbopilot --
Thanks for sharing this report. I was able to investigate today for some time, but I have not been able to replicate this crash. Could you share a simple project which replicates the issue?
I am also seeing this crash occasionally, though with WatchdogVisibility: Background.
The way this issue presents itself is that when backgrounding the app then reopening it after a while, new tiles do not load. After force closing the app and re-opening, the map tiles load as expected and there is a popup that the app crashed (sharing the crash report directly via the popup doesn't include the below crash report, but it can be found in Settings > Analytics & Improvements > Analytics Data.
Crash Logs
Hardware Model: iPhone14,5 Process: iosApp [2429] Path: /private/var/containers/Bundle/Application/FFCBA577-3CB7-4B13-B099-0C03129E1DCB/iosApp.app/iosApp Identifier: com.mbta.tid.mbtaapp.staging Version: 1.0.5 (953) AppStoreTools: 16A242d AppVariant: 1:iPhone14,5:18 Beta: YES Code Type: ARM-64 (Native) Role: Background Parent Process: launchd [1] Coalition: com.mbta.tid.mbtaapp.staging [552]Date/Time: 2024-10-07 16:59:57.1867 -0400 Launch Time: 2024-10-07 16:45:09.9167 -0400 OS Version: iPhone OS 18.0 (22A3354) Release Type: User Baseband Version: 4.02.05 Report Version: 104
Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[app<com.mbta.tid.mbtaapp.staging>:2429] Failed to terminate gracefully after 5.0s ProcessVisibility: Unknown ProcessState: Running WatchdogEvent: process-exit WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 6.550 (user 3.730, system 2.820), 18% CPU", "Elapsed application CPU time (seconds): 0.317, 1% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x1e0e0a030 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x218336a50 _pthread_cond_wait + 1204
2 libc++.1.dylib 0x1a150a584 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3 libc++.1.dylib 0x1a150ad00 std::__1::__assoc_sub_state::__sub_wait(std::__1::unique_lockstd::__1::mutex&) + 56
4 libc++.1.dylib 0x1a150ac50 std::__1::__assoc_sub_state::copy() + 56
5 libc++.1.dylib 0x1a150aff4 std::__1::future
Hey, @KaylaBrady thanks for sharing the crash log, which version of the SDK do you use?
@aleksproger this was using 11.3.0. I'm working on an upgrade to 11.7.0 to see if that will resolve the issue. With that upgrade I'm working through some new maps-core warnings after backgrounding ([Warning, maps-core]: {}[Style]: Required image 'image-name' is missing and it will not be rendered. Subscribe to StyleImageMissing event to be aware of the required missing images and add them by calling addStyleImage().). These images were previously retained after backgrounding, I'm not sure if this is related to the CleanupManager. I expect to be able to resolve these warnings but am wondering if there is a known related change that explains this behavior - nothing jumped out as me in the changelogs, and I'm having trouble finding documentation about the CleanupManager.
@KaylaBrady I suspect this problem happens when you delete annotation with image? If yes, then it's a known problem which actually shouldn't affect anything this is just incorrect log. If it's not your case please describe at which condition it happens. CleanupManager is basically an internal object and hence not documented and the warning is not related to this object.
@aleksproger this is happening occasionally after moving the app into the background for images that are used by a layer. The layer's source is not deleted when backgrounding.
We are are also noticing onStyleLoaded is being triggered after backgrounding the app which is we were not expecting. This is happening on 11.3.0 and 11.7.0 though, and may not be related to this original issue.