Heremaps native crash (SIGABRT)

Question

We're investigating on an app developed by another team a native Crash on Android related to HereMaps (HERE SDK Navigation edition, navigate-4.10.2.0.7878) with this stacktrace:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.mydomain.myapp <<<

backtrace:
  #00  pc 0000000000051010  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
  #00  pc 0000000000e0143c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e0158c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e014f4  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e01478  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000debfe4  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000144cc84  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000014035bc  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000013fa668  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000155cff0  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000011273f8  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so (Java_com_here_sdk_navigation_VisualNavigator_disposeNativeHandle+480)
  #00  pc 0000000000042020  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (art_jni_trampoline+96)
  #00  pc 000000000020988c  /apex/com.android.art/lib64/libart.so (nterp_helper+1948)
  #00  pc 0000000000b6999c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator.access$000)
  #00  pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52)
  #00  pc 0000000000b69974  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator$1.disposeNative)
  #00  pc 0000000000073c6c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (com.here.NativeBase$DisposableReference.dispose+156)
  #00  pc 000000000020a0a0  /apex/com.android.art/lib64/libart.so (nterp_helper+4016)
  #00  pc 00000000009a3834  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.cleanUpQueue+26)
  #00  pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52)
  #00  pc 00000000009a380e  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.access$100)
  #00  pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52)
  #00  pc 00000000009a37be  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>+22)
  #00  pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
  #00  pc 00000000009a37ca  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>)
  #00  pc 000000000020a748  /apex/com.android.art/lib64/libart.so (nterp_helper+5720)
  #00  pc 00000000009a37fc  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.<init>+28)
  #00  pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
  #00  pc 00000000009ac7f8  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.core.threading.RunnableImpl.<init>+10)
  #00  pc 00000000002cdd64  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548)
  #00  pc 00000000003d5660  /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallNonvirtualVoidMethodV(_JNIEnv*, _jobject*, _jclass*, _jmethodID*, std::__va_list)+492)
  #00  pc 00000000003d4ab4  /apex/com.android.art/lib64/libart.so (art::JNI<false>::NewObjectV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+736)
  #00  pc 0000000000e0e858  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e37fac  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e37a5c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000140dad0  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000144c5e8  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000144d2bc  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000000b2fd0  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264)
  #00  pc 0000000000052834  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

EDIT:

After some refactoring and cleaning operations in our code we've reached a clean condition in which we are confident that there aren't any leak; we've used LeakCanary to investigate and remove all these ones, but the native crash it's still here.

So we've tried to return back to basis and we've cloned HEREMaps Navigate Samples from github and we've found that in Navigation Sample there isn't any native crash, but there is also an only activity with heremaps instance references which die within the entire application.

To replicate a similar use case then our we've added an activity before the MainActivity of the Sample and we've tried to launch the activity and return back to the first one to show what is the behaviour of the library in terms of resources releasing.

Only opening and closing MainActivity from a starting one doesn't have any native crash also because VisualNavigator (which seems to be the class with native crash in the backtrace) is retained by it's delegates (aka Listeners) => setupListeners() in NavigationExample. So we've also removed all listeners when MainActivity calls onDestroy and in this way we see always the same native crash as in our app, going back from MainActivity to starting one.

Note: to be able to always reproduce the native crash we use LeakCanary because the library force GC when MainActivity has been destroyed; if we remove it the GC operation is done randomly by the system.

Links:

our version of HEREMaps Navigation SDK sample modified to reproduce native crash on github
video of crash of the sample: https://youtube.com/shorts/edY-TRvWh3I

So the big question here is: have we implemented wrong HEREMaps SDK integration (and managing instance releasing) or this native crash is inside the library and has to be fixed from the library owner?

score 2 · Accepted Answer · answered Jun 14 '22 at 15:59

2

Try find a way to make the VisualNavigator persistent: Using StopRendering() is fine but do not null the VisualNavigator.

I had to go through the same issue when cancelling the route too quickly, although it got way worse over the recent updates and just crashes when just stopping navigation and this fixes it.

answered Jun 14 '22 at 15:59

user13191088

36
1
5

I agree, it's what we have done at the end; it's not the best way because we're just retaining the VisualNavigator for always during application lifecycle with its persistence in memory, but it works. – ricky.tribbia Jun 16 '22 at 08:26

Nusatad · Answer 2 · 2022-04-21T20:22:08.823

0

In the HERE SDK developer's guide there is a chapter that shows how to stop navigation. It is recommended to call stopRendering(). In your example app, it seems you do not call visualNavigator.stopRendering() when the intermediate activity gets destroyed. Try to call it.

In the developer options menu of the device you can turn on "Don't keep activities" to simulate such scenarios.

edited Apr 21 '22 at 20:22

answered Apr 21 '22 at 18:13

Nusatad

3,231
3
11
17

Thank you for your answer! But adding `stopRendering` native crash is still there.. https://github.com/rickytribbia/here-sdk-examples/blob/dc0a7251013e81a7ba3c202c1f264e6563bb01cd/examples/latest/navigate/android/Navigation/app/src/main/java/com/here/navigation/NavigationExample.java#L710 – ricky.tribbia Apr 26 '22 at 13:38
I have tried your GitHub project. It does not crash for me. I can go back and forth between activities without issues. But it seems you are using a very old SDK version: navigate-4.10.2.0.7878 ... please try a newer one. There have been a lot of fixes and the code of the examples also requires a newer version. – Nusatad May 03 '22 at 18:16

Heremaps native crash (SIGABRT)

2 Answers2