Hello All,
I need to help to identify the issue with application crash randomly using runtime 100.5 and 100.6. I didn't have this issue when the app was using runtime 10.2.7.
The application is processing addresses and coordinate data to display them on the map as graphics overlay. The data is coming almost every seconds as there is a change. I already set the rendering mode as static for all graphics overlay. The application randomly crashed on the production site. I was running for 4 or 5 hours then crashed.
Here are the exception from Event Viewer.
Faulting application name: MyMap.exe, version: 4.1.18.0, time stamp: 0x5d7a4914
Faulting module name: runtimecore.dll, version: 100.6.0.2513, time stamp: 0x5d570501
Exception code: 0xc0000005
Fault offset: 0x000000000156968d
Faulting process id: 0x74
Faulting application start time: 0x01d5696ec7667b54
Faulting application path: C:\Program Files (x86)\Mapping\MyMap.exe
Faulting module path: C:\Program Files (x86)\Mapping\arcgisruntime100.6\client64\runtimecore.dll
Report Id: 3affd698-d5ae-11e9-bb16-fb9381a577cd
Application: MyMap.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
at RuntimeCoreNet.GeneratedWrappers.CoreVector.CoreRT_Vector_insert(IntPtr, Int64, IntPtr, IntPtr ByRef)
at RuntimeCoreNet.GeneratedWrappers.CoreVector.Insert(Int64, RuntimeCoreNet.GeneratedWrappers.CoreElement)
at Esri.ArcGISRuntime.RuntimeCollection`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].ExecuteActionWithUndo(System.Collections.Generic.Stack`1<System.Action>, System.Action, System.Action)
at Esri.ArcGISRuntime.RuntimeCollection`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetItem(Int32, System.__Canon)
at Esri.ArcGISRuntime.RuntimeObservableCollection`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetItem(Int32, System.__Canon)
at MyMapControl.AddGraphicsOverlay(MyList, Esri.ArcGISRuntime.UI.GraphicsOverlay, System.String)
at MyMapControl.AddGraphicsOverlay(MyList)
at MyMapControl.PlotMapPoint()
at MyMapControl+<GeoCodeMyItem>d__187.MoveNext()
at System.Runtime.CompilerServices.AsyncVoidMethodBuilder.Start[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.__Canon ByRef)
at MyMapControl.GeoCodeMyItem()
at MyMapControl.DrawMapPoint()
at MyMapControl.MapRefreshChangedWorker_RunWorkerCompleted(System.Object, System.ComponentModel.RunWorkerCompletedEventArgs)
at System.ComponentModel.BackgroundWorker.OnRunWorkerCompleted(System.ComponentModel.RunWorkerCompletedEventArgs)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
at System.Windows.Application.RunDispatcher(System.Object)
at System.Windows.Application.RunInternal(System.Windows.Window)
at WpfCadMap.App.Main()
I am not able to reproduce the problem.
Thanks,
Steven
We're seeing an extremely similar issue with ArcGIS Runtime 100.6 (Xamarin Forms 4.2), our application is frequently crashing and auto restarting (many times per hour on occasion).
Faulting module name: runtimecore.dll, version 100.6.0.2513, time stamp: 0x5d5705ee. Exception code: 0xc0000005
We didn't have this issue with the 100.2.x version we used with XF 2.x.
Is there a feature in the ArcGIS Runtime which we can enable which logs out debug level activity of what calls/actions are being made by our LoB application to the map control? e.g. change base layer, add feature layer, go to Lng/Lat etc.
Thanks
Bryan
Hi,
Is it a Xamarin Forms UWP application?
Debug symbol files for the 100.6 WPF and UWP APIs have recently been made available: you can find details on how to use them to get a call stack in this post: https://community.esri.com/community/developers/native-app-developers/arcgis-runtime-sdk-for-net/blo...
Regards
Mike
Excellent, will get our devs across this and feedback. Thank you.
As an update to this Michael, we've rolled back to 100.4 and we're not seeing the frequent app crashes anymore. We'll continue with 100.6 in parallel to continue the debugging as per the article above. Thanks for your help.
As a side note, we too use RouteTask.SolveRouteAsync() (as mentioned in the article) however we are specifying the SpatialReference when creating MapPoint geometries to represent Stops.
Hi Michael,
We've managed to capture the stack trace for when our UWP application crashes:
> runtimecore.dll!std::vector<int,class std::allocator<int> >::_Emplace_reallocate<int &>(int * const,int &) Unknown
runtimecore.dll!Esri_runtimecore::Map_renderer::Labelable::label_class_ids(void) Unknown
runtimecore.dll!Esri_runtimecore::Map_renderer::Dynamic_layer_current::update_entities_(class std::vector<class Esri_runtimecore::Geometry::Envelope_2D,class std::allocator<class Esri_runtimecore::Geometry::Envelope_2D> > const &) Unknown
runtimecore.dll!<lambda>(void)() Unknown
runtimecore.dll!std::_Func_impl_no_alloc<<lambda_afe6e24629c3913758f1a9575b5fdf4f>,unsigned char>::_Do_call() Unknown
runtimecore.dll!pplx::task<unsigned char>::_InitialTaskHandle<void,<lambda>(void),pplx::details::_TypeSelectorNoAsync>::_LogWorkItemAndInvokeUserLambda<std::function<unsigned char __cdecl(void)>>() Unknown
runtimecore.dll!pplx::task<unsigned char>::_InitialTaskHandle<void,<lambda>(void),pplx::details::_TypeSelectorNoAsync>::_Init() Unknown
runtimecore.dll!pplx::details::_PPLTaskHandle<unsigned char,pplx::task<unsigned char>::_InitialTaskHandle<void,<lambda>(void),pplx::details::_TypeSelectorNoAsync>,pplx::details::_TaskProcHandle>::invoke() Unknown
runtimecore.dll!pplx::details::_TaskProcHandle::_RunChoreBridge(void *) Unknown
runtimecore.dll!Esri_runtimecore::Common::Core_scheduler::invoke_(struct Esri_runtimecore::Common::Core_scheduler::Queued_proc *) Unknown
runtimecore.dll!Esri_runtimecore::Common::Core_scheduler::Queued_proc::invoke(void) Unknown
runtimecore.dll!Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void *) Unknown
runtimecore.dll!Esri_runtimecore::Common::Windows_Threadpool_scheduler::Scheduler_param::work_callback(struct _TP_CALLBACK_INSTANCE *,void *,struct _TP_WORK *) Unknown
ntdll.dll!00007ff9ddaa849c() Unknown
ntdll.dll!00007ff9ddaa6a29() Unknown
kernel32.dll!00007ff9dba14034() Unknown
ntdll.dll!00007ff9ddaf3691() Unknown
Not being an expect in the depths of the ArcGIS Runtime, I suspect the issue lies in the following area:
> runtimecore.dll!std::vector<int,class std::allocator<int> >::_Emplace_reallocate<int &>(int * const,int &) Unknown
runtimecore.dll!Esri_runtimecore::Map_renderer::Labelable::label_class_ids(void) Unknown
runtimecore.dll!Esri_runtimecore::Map_renderer::Dynamic_layer_current::update_entities_(class std::vector<class Esri_runtimecore::Geometry::Envelope_2D,class std::allocator<class Esri_runtimecore::Geometry::Envelope_2D> > const &) Unknown
Would you be able to assist with pointing us in the direction of what ArcGIS Runtime calls from the API we'd need to focus in on? (maybe Esri.ArcGISRuntime.Layers.DynamicLayer)
Thanks
Bryan
Bryan,
Thanks for the additional info. The `Dynamic_layer_current` mentioned above refers to the GraphicsRenderingMode Enumeration or FeatureRenderingMode Enumeration. The call stack appears to stop during some logic relating to labeling.
Have you written any code specifically relating to labeling and label classes of GraphicsOverlays or FeatureLayers? If so are you able to share that as a standalone reproducer?
Alternatively, perhaps your code is opening mobile or web maps that contain layers with labels. In which case, are you able to share details of those?
Regards
Mike
Bryan,
I have some good news - the native call stack you provided enabled colleagues on our labeling / rendering teams to identify an area of code that should be protected during multi-threaded access. A candidate fix has been proposed, reviewed, and merged into our development branch. All being well, it should be included in the upcoming 100.7 release in late-Q4 2019 / early-Q1 2020.
Regards
Mike
Hi Michael,
This is good news - pleased we can help identify a bug . So for our LoB application we're doing a couple of things - we've got two builds running in debug mode, one with FeatureLayers related code disabled and one with GraphicsOverlays relate code disabled.
Overnight the build with GraphicsOverlays related code disabled didn't crash and the build with the FeatureLayers disabled did crash overnight with the same issue.
We're now focusing on which specific GraphicsOverlays layer - we have 4 being used in our app, other Fire Appliance(s) position, Buildings, Route Line (network dataset), current Location Marker & Destination Marker).
If we're able to pin point a specific GraphicsOverlays which is giving us the trouble we can then possibly look at workarounds? - with respects to the future fix, is there a chance of a hotfix? If not and we can't do a workaround we'll need to drop back to 100.4 (assuming 100.5 has this same issue).
Appreciate your help on this matter.
Thanks
Bryan