requestOperation.data crash investigation

Question

From time to time I'm encountering crash during launching the application. Runtime SDK version 100.6 Thread 8: EXC_BAD_ACCESS (code=1, address=0x0) Thread 8 Queue : com.esri.arcgis.requestOperation.data (serial) #0 0x000000010a72e08e in void std::__1::__tree_balance_after_insert*>(std::__1::__tree_node_base*, std::__1::__tree_node_base*) () I've tried to execute po (SEL)$arg2 but the result is (SEL)$arg3 -> " \xffffffd2\xffffff91" (SEL)$arg5 -> "\x01/attriba" Can someone take a look for the Runtime SDK source code in order to examine which methods are using the "com.esri.arcgis.requestOperation.data" serial queue? It might help to understand where the problem is.

SerhiiKyrylenko · Answer

Sure, here is back trace for the thread where crash is happening: * thread #17, queue = 'com.esri.arcgis.requestOperation.data', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000102dfe08e ArcGIS`void std::__1::__tree_balance_after_insert*>(std::__1::__tree_node_base*, std::__1::__tree_node_base*) + 190 frame #1: 0x0000000103e5924d ArcGIS`Esri_runtimecore::Geo_model::ArcGIS_map_service_attribution_info::attribution_URL_for_service_URL(std::__1::basic_string, std::__1::allocator > const&) + 7949 frame #2: 0x000000010392bf7d ArcGIS`Esri_runtimecore::Geo_model::ArcGIS_tiled_source::set_URI(std::__1::basic_string, std::__1::allocator >) + 637 frame #3: 0x000000010392bc65 ArcGIS`Esri_runtimecore::Geo_model::ArcGIS_tiled_source::create_from_URI(std::__1::basic_string, std::__1::allocator >) + 85 frame #4: 0x0000000103cf3897 ArcGIS`Esri_runtimecore::Geo_model::create_raster_tiled_datasource(std::__1::basic_string, std::__1::allocator >, std::__1::basic_string, std::__1::allocator > const&, Esri_runtimecore::Geo_model::Deserialization_context&) + 327 frame #5: 0x0000000103cf8393 ArcGIS`Esri_runtimecore::Geo_model::deserialize(Esri_runtimecore::ArcGIS_rest::Basemap_layer const&, Esri_runtimecore::Geo_model::Deserialization_context&) + 3091 frame #6: 0x0000000103c4b772 ArcGIS`Esri_runtimecore::Geo_model::deserialize_basemap(Esri_runtimecore::Geo_model::Basemap&, Esri_runtimecore::ArcGIS_rest::Basemap&, Esri_runtimecore::Geo_model::Deserialization_context&) + 706 frame #7: 0x0000000103db2f80 ArcGIS`Esri_runtimecore::Geo_model::deserialize(Esri_runtimecore::Geo_model::Map&, Esri_runtimecore::ArcGIS_rest::Webmap const&, Esri_runtimecore::Geo_model::Deserialization_context&) + 960 frame #8: 0x00000001039caf88 ArcGIS`Esri_runtimecore::Geo_model::Map::load_from_data_(unsigned char const*, unsigned long, std::exception_ptr const&) + 808 frame #9: 0x00000001039d0776 ArcGIS`std::__1::__function::__func, void (std::__1::shared_ptr > >, std::exception_ptr)>::operator()(std::__1::shared_ptr > >&&, std::exception_ptr&&) + 86 frame #10: 0x0000000103e0400d ArcGIS`Esri_runtimecore::Common::Slot)>::target_model > >, std::exception_ptr)>, pplx::cancellation_token const&, bool)::$_6>::invoke(void const*, unsigned char const*, unsigned long, std::__1::reference_wrapper >) + 877 frame #11: 0x0000000105b9a4eb ArcGIS`Esri_runtimecore::Common::Signal_detail::Signal_base::notify_(Esri_runtimecore::Common::Function_ref) const + 603 frame #12: 0x0000000103df7239 ArcGIS`Esri_runtimecore::Geo_model::Portal_item::handle_response_(std::__1::shared_ptr const&, unsigned char const*, unsigned long, std::__1::shared_ptr const&) + 1833 frame #13: 0x0000000105b90e92 ArcGIS`Esri_runtimecore::Common::Request_delegator::handle_response(unsigned long long, unsigned char const*, unsigned long, std::__1::shared_ptr const&) + 130 frame #14: 0x0000000105b8d4f0 ArcGIS`Esri_runtimecore::Common::Request::handle_response(unsigned char const*, unsigned long, std::__1::shared_ptr const&) + 112 frame #15: 0x0000000103151f68 ArcGIS`RT_Request_handleResponse + 168 frame #16: 0x0000000102b48479 ArcGIS`-[RTCRequest handleResponse:userDefinedError:error:] + 231 frame #17: 0x0000000102d1bac2 ArcGIS`__71+[AGSRTCRequestDispatcher ags_kickOffCoreRequest:forRequestDispatcher:]_block_invoke.202 + 1420 frame #18: 0x0000000102d45bae ArcGIS`__38-[AGSObservableOperation didComplete:]_block_invoke + 325 frame #19: 0x0000000102b9f02e ArcGIS`ags_runWithMainThread + 66 frame #20: 0x0000000102d45a47 ArcGIS`-[AGSObservableOperation didComplete:] + 264 frame #21: 0x0000000102c65918 ArcGIS`-[AGSRequestOperation didComplete:] + 370 frame #22: 0x0000000102d45896 ArcGIS`-[AGSObservableOperation finishWithResult:error: ] + 132 frame #23: 0x0000000102c6a367 ArcGIS`-[AGSRequestOperation finishWithResult:error: ] + 773 frame #24: 0x0000000102c67f2e ArcGIS`-[AGSRequestOperation requestOperationDidFinishLoading] + 595 frame #25: 0x0000000102c67677 ArcGIS`-[AGSRequestOperation handleRequestCompletionWithError:] + 315 frame #26: 0x000000010a5bfdd4 libdispatch.dylib`_dispatch_call_block_and_release + 12 frame #27: 0x000000010a5c0d48 libdispatch.dylib`_dispatch_client_callout + 8 frame #28: 0x000000010a5c75ef libdispatch.dylib`_dispatch_lane_serial_drain + 788 frame #29: 0x000000010a5c817f libdispatch.dylib`_dispatch_lane_invoke + 422 frame #30: 0x000000010a5d3a4e libdispatch.dylib`_dispatch_workloop_worker_thread + 719 frame #31: 0x00007fff51c0171b libsystem_pthread.dylib`_pthread_wqthread + 290 frame #32: 0x00007fff51c0157b libsystem_pthread.dylib`start_wqthread + 15 My guesses: may be it's because of creating two or more map objects... previously I've encountered 100% crash while trying to display two map views on the same screen. Current application displays only one map view, but creates and loads few map objects. Isn't that an anti-pattern for the Runtime SDK and AGSMap instance should be globally visible singleton object instead? P.S. Following my guess. Looks like trick with the singleton map object did the job for me. Crash is absent so far.

Nicholas-Furness · Answer

Anything that makes a network request will use requestOperation. Can you provide more of the stack trace?