App Freeze [AGSMapViewCommon setMap:]

[RTC]

Our customers are reporting that our app is freezing and then crashing. This seems to be happening with iOS 17.4  and 17.5. The crash reports are all from Watchdog terminating the app and are pointing to something in the Esri SDK referencing [AGSMapViewCommon setMap:].  Any thoughts on what could be causing the issue?

Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: FRONTBOARD 2343432205
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[app<XXXXXXX)>:454] failed to terminate gracefully after 5.0s
ProcessVisibility: Unknown
ProcessState: Running
WatchdogEvent: process-exit
WatchdogVisibility: Background
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 9.760 (user 6.810, system 2.950), 21% CPU",
"Elapsed application CPU time (seconds): 0.027, 0% 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
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 0x1d877a3ec __semwait_signal + 8
1 libsystem_c.dylib 0x1976275f0 nanosleep + 220
2 libc++.1.dylib 0x19faf05ac std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l>> const&) + 84
3 Runtimecore 0x10ad4275c void std::__1::this_thread::sleep_for<long long, std::__1::ratio<1l, 1000l>>(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000l>> const&) + 72
4 Runtimecore 0x10b5b6d20 esri::Vector_tiles::Vector_tiles_service::shutdown_service() + 68
5 Runtimecore 0x10b05db8c esri::map_renderer::Vector_tile_layer::on_unbind_from_map_() + 36
6 Runtimecore 0x10b02a6d8 esri::map_renderer::Layer_2D::unbind_from_map(bool) + 132
7 Runtimecore 0x10b036008 esri::map_renderer::Map::remove_layer(esri::map_renderer::Layer_info const&) + 116
8 Runtimecore 0x10a6bc830 esri::geoview::Geo_view_mr::remove_renderer_layers_(esri::geoview::Geo_view_mr::Collection_type) + 96
9 Runtimecore 0x10a6bc738 esri::geoview::Geo_view_mr::disconnect_operational_layers_(esri::common::Visitor_ptr<esri::geomodel::Layer_collection> const&) + 40
10 Runtimecore 0x10a6c0afc esri::geoview::Geo_view_mr::disconnect_from_geodoc_() + 400
11 Runtimecore 0x10a6ead68 esri::geoview::Map_view_mr::disconnect_from_geodoc_() + 36
12 Runtimecore 0x10a6ef33c esri::geoview::Map_view_mr_impl::set_map(esri::common::Visitor_ptr<esri::geomodel::Map> const&) + 72
13 Runtimecore 0x10a439324 RT_MapView_setMap + 52
14 ArcGIS 0x103fbc248 -[AGSMapViewCommon setMap:] + 156

[Nicholas-Furness]

At first glance it looks like the user is setting a map on the MapView when the MapView already has a map on it (i.e. replace the MapView's map).

As part of tearing down the old map, it seems that we're disconnecting from a vector tile service and waiting for it to disconnect in some way. That shouldn't be happening on the main thread (I'm sure we should never call thread.sleep (see frame 3) on the main thread).

Presumably setting the map is done as the result of a user action (e.g. tapping a button), but to help dig in: are there more frames after frame 14 in the crash (frames 15 and higher)?

[RTC]

Thanks for the reply! Yes, you are correct, this is happening when the map is being changed by the user.  Here are the additional likes of the crashed thread (0):

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x1d877a3ec __semwait_signal + 8
1 libsystem_c.dylib 0x1976275f0 nanosleep + 220
2 libc++.1.dylib 0x19faf05ac std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l>> const&) + 84
3 Runtimecore 0x10ad4275c void std::__1::this_thread::sleep_for<long long, std::__1::ratio<1l, 1000l>>(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000l>> const&) + 72
4 Runtimecore 0x10b5b6d20 esri::Vector_tiles::Vector_tiles_service::shutdown_service() + 68
5 Runtimecore 0x10b05db8c esri::map_renderer::Vector_tile_layer::on_unbind_from_map_() + 36
6 Runtimecore 0x10b02a6d8 esri::map_renderer::Layer_2D::unbind_from_map(bool) + 132
7 Runtimecore 0x10b036008 esri::map_renderer::Map::remove_layer(esri::map_renderer::Layer_info const&) + 116
8 Runtimecore 0x10a6bc830 esri::geoview::Geo_view_mr::remove_renderer_layers_(esri::geoview::Geo_view_mr::Collection_type) + 96
9 Runtimecore 0x10a6bc738 esri::geoview::Geo_view_mr::disconnect_operational_layers_(esri::common::Visitor_ptr<esri::geomodel::Layer_collection> const&) + 40
10 Runtimecore 0x10a6c0afc esri::geoview::Geo_view_mr::disconnect_from_geodoc_() + 400
11 Runtimecore 0x10a6ead68 esri::geoview::Map_view_mr::disconnect_from_geodoc_() + 36
12 Runtimecore 0x10a6ef33c esri::geoview::Map_view_mr_impl::set_map(esri::common::Visitor_ptr<esri::geomodel::Map> const&) + 72
13 Runtimecore 0x10a439324 RT_MapView_setMap + 52
14 ArcGIS 0x103fbc248 -[AGSMapViewCommon setMap:] + 156
15 MyFramework 0x1050d5668 0x104d24000 + 3872360
16 MyApp 0x1029d5d00 0x1028fc000 + 892160
17 MyApp 0x1029d5d60 0x1028fc000 + 892256
18 libsystem_blocks.dylib 0x1ec4d3b74 bool HelperBase<GenericInline>::disposeCapture<(HelperBase<GenericInline>::BlockCaptureKind)3>(unsigned int, unsigned char*) + 68
19 libsystem_blocks.dylib 0x1ec4d36dc HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 160
20 libsystem_blocks.dylib 0x1ec4d31c8 _call_dispose_helpers_excp + 72
21 libsystem_blocks.dylib 0x1ec4d3164 _Block_release + 252
22 UIKitCore 0x1919e06f0 -[_UIAfterCACommitBlock run] + 84
23 UIKitCore 0x1919e05a8 -[_UIAfterCACommitQueue flush] + 164
24 UIKitCore 0x1919e04c0 _runAfterCACommitDeferredBlocks + 496
25 UIKitCore 0x1919e00f8 _cleanUpAfterCAFlushAndRunDeferredBlocks + 80
26 UIKitCore 0x1919e0008 _UIApplicationFlushCATransaction + 72
27 UIKitCore 0x1919dd76c _UIUpdateSequenceRun + 84
28 UIKitCore 0x1919dd3b0 schedulerStepScheduledMainSection + 172
29 UIKitCore 0x1919de254 runloopSourceCallback + 92
30 CoreFoundation 0x18f6fb834 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
31 CoreFoundation 0x18f6fb7c8 __CFRunLoopDoSource0 + 176
32 CoreFoundation 0x18f6f9298 __CFRunLoopDoSources0 + 244
33 CoreFoundation 0x18f6f8484 __CFRunLoopRun + 828
34 CoreFoundation 0x18f6f7cd8 CFRunLoopRunSpecific + 608
35 GraphicsServices 0x1d45a81a8 GSEventRunModal + 164
36 UIKitCore 0x191d3090c -[UIApplication _run] + 888
37 UIKitCore 0x191de49d0 UIApplicationMain + 340
38 MyApp main (MyAppDelegate.swift:19)
39 dyld 0x1b2da9e4c start + 2240

[Nicholas-Furness]

Thanks for that additional info. Yeah. Something is causing the SDK to wait for a while when removing a vector tile layer. iOS doesn't tolerate that happening on the main thread (which makes the app unresponsive), and so is terminating the app.

A couple of questions:

1. Which version of the SDK are you on?
2. Are you able to reproduce this yourself? If so, can you share a simple reproducer?

[RTC]

1. We are currently using 100.15.2, we tried 100.15.4 but saw the same issues so we rolled back to .2
2. I can recreate it on my device, I will need to work on creating a simplified version to share

[RTC]

I have a simple project that reproduces the error. I will open a support ticket for this item so my organization can track it.

[RTC]

I am getting the sample app ready to upload.