CoreBasemap.nativeDestroy - Crash

[NicoleLeiva]

Hello! Since we have migrated to the 200.x version we started seeing this crash for many users. We also know that some of the users were not having the map view opened at the time when they got this crash.

This is all the info that we are getting from the stack trace :

 Fatal Exception: java.util.concurrent.TimeoutException: com.arcgismaps.internal.jni.CoreBasemap.finalize() timed out after 60 seconds
       at com.arcgismaps.internal.jni.CoreBasemap.nativeDestroy(CoreBasemap.java)
       at com.arcgismaps.internal.jni.CoreBasemap.disposeInner(CoreBasemap.java:548)
       at com.arcgismaps.internal.jni.CoreBasemap.finalize(CoreBasemap.java:509)
       at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:370)
       at java.lang.Daemons$FinalizerDaemon.processReference(Daemons.java:350)
       at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:322)
       at java.lang.Daemons$Daemon.run(Daemons.java:131)
       at java.lang.Thread.run(Thread.java:1012)

 
Any guidance to understand better this crash will be appreciated. Thanks! 

[Shubham_Sharma]

Hello @NicoleLeiva,

Thank you for reaching out regarding the crash issue. To better understand and diagnose the problem, could you please provide us with more details? Here are a few questions that might help us narrow down the cause:

• Could you provide a reproducible case or steps to replicate the crash?
• Which specific version 200.x did this crash occur on? Is it happening across all versions in the 200.x?
• On which API level does this crash predominantly occur?
• Is the MapView being displayed using View or Compose?
• Is the MapView rendering locally available maps, or is it utilizing online resources?
• Are there multiple instances of MapView being used simultaneously in the application?
• Is the MapView being rendered as part of an activity or fragment? If so, could you provide details on its lifecycle management?
• Are there any specific user environments (e.g., device models, OS versions) where this crash is more prevalent?
• How frequently are users experiencing this crash? Is it isolated to certain actions or events within the app?

Your insights on these questions will greatly assist us in diagnosing the issue. 

[NicoleLeiva]

Hi!  @Shubham_Sharma ,

I'll provide you here the answer for those questions

• Could you provide a reproducible case or steps to replicate the crash? 

We were not able yet to reproduce the crash.

• Which specific version 200.x did this crash occur on? Is it happening across all versions in the 200.x?

Currently, we are using 200.5.0. I would say "yes" to the second question, considering that we started seeing that error when we did the migration from 100.x sdk to 200.x

• On which API level does this crash predominantly occur?

Not sure about it. The information that I attached at the beginning of the post is all the information from the stack trace that we are getting.

• Is the MapView being displayed using View or Compose?

Yes, the MapView is being displayed using View.

• Is the MapView rendering locally available maps, or is it utilizing online resources?

From the user replays we can say that sometimes is in offline mode and others using online resources.

• Are there multiple instances of MapView being used simultaneously in the application?

No

• Is the MapView being rendered as part of an activity or fragment? If so, could you provide details on its lifecycle management?

The MapsView is being rendered as part of a fragment.

• Are there any specific user environments (e.g., device models, OS versions) where this crash is more prevalent?

Nothing special.

• How frequently are users experiencing this crash? Is it isolated to certain actions or events within the app?

It not happen all the time but a considerable amount of user had experience this. We did not find any pattern to replicate this crash until the moment.

[Shubham_Sharma]

Thank you for providing these additional details. We’ve recorded your response and will continue to investigate the crash based on the information you’ve shared. We appreciate your patience and will work toward a fix in a future release of the SDK.