Application randomly crashed using the run time version 100.5 and 100.6

2699
12
09-13-2019 08:04 AM
StevenLam1
New Contributor II

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

0 Kudos
12 Replies
MichaelBranscomb
Esri Frequent Contributor

Hi,

Can you share a reproducer? If not here, you can email mbranscomb@esri.com.

Thanks

Mike

0 Kudos
BryanWilson
New Contributor II

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

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

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

BryanWilson
New Contributor II

Excellent, will get our devs across this and feedback.  Thank you. 

0 Kudos
BryanWilson
New Contributor II

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.

0 Kudos
BryanWilson
New Contributor II

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

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

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

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

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 

0 Kudos
BryanWilson
New Contributor II

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

0 Kudos