Getting NULL in Geo_view::schedule_update_attribution_()...

1313
12
03-19-2018 04:39 PM
JakeShapley
New Contributor III

Hi,

We have an iOS app out on the App Store. We recently updated to 100.2.1 and started getting crashes caused by:

#1 (null) in std::__1::__function::__func<Esri_runtimecore::Mapping::Geo_view::schedule_update_attribution_()::$_59, std::__1::allocator<Esri_runtimecore::Mapping::Geo_view::schedule_update_attribution_()::$_59>, void ()>::operator()() ()

Unfortunately, we have not been able to reproduce it and these crashes are unsymbolicated, despite the fact that I selected option to include symbols when I uploaded the build (and, yes, this is the same machine that has the original archive on it). Thoughts on what would cause this? Based on your documentation, I know the method is associated with map attribution. We are not altering the display, etc. of the attribution at all.

Cheers,

Jake

0 Kudos
12 Replies
MarkDostal
Esri Contributor

Jake,

Sorry to hear you're having problems.  Can you give me any additional information about the crash, such as:

- does it happen with a mapView or SceneView (or both)?

- does it happen during any particular operation/task/user input?

- is there any particular layers/maps/scenes/basemap/data that causes it to happen more often or not?

- any particular device (example: iPhone 6 or 7s or iPad)?

- any particular iOS version?

The method in question is called when there are changes to the map/scene that would require updating the attribution text; things such as adding/removing layers, changing base map layers, and just updating the visible area of the map/scene (as different data may become visible/hidden).

Mark

0 Kudos
JakeShapley
New Contributor III

Hi Mark,

We are only using mapView.

I'm not sure what the user is doing. We have over 5k installs, but 5 instances of this particular crash. Based on what's on the UI thread, I assume it is instantiating or otherwise responding to a vector base layer. This is on the main thread at the time of crash (note: we are only using one built-in vector basemap via a service, .darkGrayCanvasVector; though we also have a custom vtpk onboard):

#0 (null) in std::__1::__vector_base<unsigned int, std::__1::allocator<unsigned int> >::~__vector_base() ()

I see them for only iPhone. 6s Plus; iOS 11.2.6

I figured it was something like that. I've attempted unsuccessfully to reproduce the behavior by: 1) switching out the basemap to/from both the .darkGrayCanvasVector and the .vtpk multiple times; 2) panning and zooming the map; 3) backgrounding/foregrounding the app with both layers instantiated; 4) Force-quitting/relaunching with both layers instantiated.

Jake

0 Kudos
MarkDostal
Esri Contributor

Thank you for the additional information.  I'm going to do some research on my end.

Mark

0 Kudos
JakeShapley
New Contributor III

Hi Mark,

We are apparently getting a similar crash with the Android version of our app:

Today, 8:30 AM on app version 17
Samsung Galaxy S8 (dreamqltesq), 4096MB RAM, Android 7.0
Report 1
com.esri.arcgisruntime.ArcGISRuntimeException:
at com.esri.arcgisruntime.internal.jni.CoreGeoView.nativeGetAttributionText (Native Method)
at com.esri.arcgisruntime.internal.jni.CoreGeoView.b (SourceFile:152)
at com.esri.arcgisruntime.internal.g.b.g.f (SourceFile:978)
at com.esri.arcgisruntime.mapping.view.GeoView$3.attributionTextChanged (SourceFile:954)
at com.esri.arcgisruntime.internal.g.b.b$1.run (SourceFile:50)
at android.os.Handler.handleCallback (Handler.java:751)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6776)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1520)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)
0 Kudos
MarkDostal
Esri Contributor

Jake,

Thanks for the info.  It looks like it might be a problem on our end, but I'll keep you posted, especially if I can find a work-around.

Mark

0 Kudos
MarkDostal
Esri Contributor

Jake,  one more question:  Is this in a mapView or sceneView?

Thanks.

0 Kudos
JakeShapley
New Contributor III

Hi Mark,

We're only using mapView.

A workaround would be awesome. We already have listeners setup for when the map is panned/zoomed in both apps, so I'm hoping we can override and wrap those attribution text methods with a try/catch or similar (assuming, of course that those parts of the API are exposed...).

Jake

0 Kudos
JakeShapley
New Contributor III

Hi Mark,

Any update on this? Our app is out in the wild, with over 15k installs as of yesterday and this issue is causing a high hard crash rate (~5%) for both iOS and Android. We still haven't been able to reproduce ourselves. I did send support a request to open a case yesterday, as well, but I haven't got a reply yet. At this point, a workaround of some sort would be just fine.

Cheers,

Jake

0 Kudos
MarkDostal
Esri Contributor

Jake,

Can you try setting the AGSGeoView.isAttributionTextVisible property to false?  This will hide the attribution text view and should prevent the issue from happening.

We are continuing to debug the issue here to see if there's a permanent fix.

Mark

0 Kudos