Android native crash

Question

We are not using any native code, as well our app doesn't have any native transitive dependency.

After recent release (we updated couple fo dependencies and add new) we started seeing crashes like this in Google Play:

native: pc 000000000006a548  /system/lib64/libc.so (tgkill+8)
  native: pc 0000000000067cd8  /system/lib64/libc.so (pthread_kill+68)
  native: pc 0000000000024b78  /system/lib64/libc.so (raise+28)
  native: pc 000000000001f318  /system/lib64/libc.so (abort+60)
  native: pc 000000000043471c  /system/lib64/libart.so (_ZN3art7Runtime5AbortEv+324)
  native: pc 0000000000137224  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+3136)
  native: pc 000000000030d988  /system/lib64/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+2080)
  native: pc 000000000030df24  /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortFEPKcS2_z+224)
  native: pc 000000000034ec64  /system/lib64/libart.so (_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+616)
  native: pc 0000000000099094  /system/lib64/libandroid_runtime.so
  native: pc 0000000002a71ac4  /system/framework/arm64/boot.oat

I think it just Android itself but what might be the reason? Any assistance is appreciated.

Is there info about what this call means? Is it virtual machine some invocation?

_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list

Answer 1

To start out I think the troublesome issue was finding the root cause as the Play Console does not provide the full stack trace and the stack trace also changes slightly depending on the device/android version. I have seen this tgkill native crash with many variations like the following but I've concluded that all of these crashes can be attributed to a bug in the Support Library

_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+440 _ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+616 art::JNI::CallVoidMethodV(_JNIEnv*, _jobject*, _jmethodID*, std::__va_list)+580 _ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+470 _ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+560

After much effort I was able to recreate this on a 6.0 Device on a screen in my application that contained an AppBarLayout + CollapsingToolbarLayout + RecyclerView. The CollapsingToolbarLayout had the following scroll flags

app:layout_scrollFlags="scroll|exitUntilCollapsed|snap"

By scrolling all the way to the bottom and then quickly back to the top I was able to recreate the crash most of the time which yielded the following stacktrace

04-18 14:06:53.814 27077-27077/com.PACKAGE.NAME.debug A/art: art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: can't call void android.view.View.setElevation(float) on null object
art/runtime/java_vm_ext.cc:410]     in call to CallVoidMethodV
art/runtime/java_vm_ext.cc:410]     from void android.animation.PropertyValuesHolder.nCallFloatMethod(java.lang.Object, long, float)
art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable
art/runtime/java_vm_ext.cc:410]   | group="main" sCount=0 dsCount=0 obj=0x740f26e8 self=0x558c24bf70
art/runtime/java_vm_ext.cc:410]   | sysTid=27077 nice=-6 cgrp=default sched=0/0 handle=0x7f8f6e8fc8
art/runtime/java_vm_ext.cc:410]   | state=R schedstat=( 76543056125 12869243427 123563 ) utm=6830 stm=824 core=2 HZ=100
art/runtime/java_vm_ext.cc:410]   | stack=0x7fef761000-0x7fef763000 stackSize=8MB
art/runtime/java_vm_ext.cc:410]   | held mutexes= "mutator lock"(shared held)
art/runtime/java_vm_ext.cc:410]   native: #00 pc 00000000004903d8  /system/lib64/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiPKcPNS_9ArtMethodEPv+236)
art/runtime/java_vm_ext.cc:410]   native: #01 pc 000000000045f598  /system/lib64/libart.so (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+220)
art/runtime/java_vm_ext.cc:410]   native: #02 pc 0000000000312970  /system/lib64/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+1000)
art/runtime/java_vm_ext.cc:410]   native: #03 pc 0000000000313228  /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+116)
art/runtime/java_vm_ext.cc:410]   native: #04 pc 000000000014501c  /system/lib64/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+144)
art/runtime/java_vm_ext.cc:410]   native: #05 pc 000000000014557c  /system/lib64/libart.so (_ZN3art11ScopedCheck17CheckMethodAndSigERNS_18ScopedObjectAccessEP8_jobjectP7_jclassP10_jmethodIDNS_9Primitive4TypeENS_10InvokeTypeE+1084)
art/runtime/java_vm_ext.cc:410]   native: #06 pc 000000000015eaf8  /system/lib64/libart.so (_ZN3art8CheckJNI11CallMethodVEPKcP7_JNIEnvP8_jobjectP7_jclassP10_jmethodIDSt9__va_listNS_9Primitive4TypeENS_10InvokeTypeE+724)
art/runtime/java_vm_ext.cc:410]   native: #07 pc 0000000000160d98  /system/lib64/libart.so (_ZN3art8CheckJNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+68)
art/runtime/java_vm_ext.cc:410]   native: #08 pc 0000000000098fe0  /system/lib64/libandroid_runtime.so (???)
art/runtime/java_vm_ext.cc:410]   native: #09 pc 0000000000ad2cc4  /system/framework/arm64/boot.oat (Java_android_animation_PropertyValuesHolder_nCallFloatMethod__Ljava_lang_Object_2JF+168)
art/runtime/java_vm_ext.cc:410]   at android.animation.PropertyValuesHolder.nCallFloatMethod(Native method)
art/runtime/java_vm_ext.cc:410]   at android.animation.PropertyValuesHolder.access$400(PropertyValuesHolder.java:37)
art/runtime/java_vm_ext.cc:410]   at android.animation.PropertyValuesHolder$FloatPropertyValuesHolder.setAnimatedValue(PropertyValuesHolder.java:1296)
art/runtime/java_vm_ext.cc:410]   at android.animation.ObjectAnimator.animateValue(ObjectAnimator.java:981)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator.animationFrame(ValueAnimator.java:1384)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator.doAnimationFrame(ValueAnimator.java:1427)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator$AnimationHandler.doAnimationFrame(ValueAnimator.java:759)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator$AnimationHandler$1.run(ValueAnimator.java:801)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer$CallbackRecord.run(Choreographer.java:858)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer.doCallbacks(Choreographer.java:670)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer.doFrame(Choreographer.java:603)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:844)
art/runtime/java_vm_ext.cc:410]   at android.os.Handler.handleCallback(Handler.java:743)
art/runtime/java_vm_ext.cc:410]   at android.os.Handler.dispatchMessage(Handler.java:95)
art/runtime/java_vm_ext.cc:410]   at android.os.Looper.loop(Looper.java:171)
art/runtime/java_vm_ext.cc:410]   at android.app.ActivityThread.main(ActivityThread.java:5417)
art/runtime/java_vm_ext.cc:410]   at java.lang.reflect.Method.invoke!(Native method)
art/runtime/java_vm_ext.cc:410]   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
art/runtime/java_vm_ext.cc:410]   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
art/runtime/java_vm_ext.cc:410] 

The root cause of this seems to be related to a Support Library bug detailed here and here

SOLUTION

In my case all I had to do was remove the snap scroll flag and rollout that change. With that change I am not seeing any of these native crashes anymore in Play Console.

In other cases if you are using a StateListAnimator on the AppBarLayout you can try this

Answer 2

I was so sceptical about some dependency bug as a possible cause of the crash(es).

However, we've updated next in the latest release and crash disappears:

• Build tools 26.0.3 -> 27.0.3
• Android Gradle Plugin to 3.0.1 -> 3.1.0-rc01 (this also brings new data binding dependencies under the hood)
• DexGuard 8.0.23 -> 8.1.10
• Kotlin 1.2.21 -> 1.2.30
• RxJava 2.1.0 -> 2.1.10
• RxAndroid 2.0.1 -> 2.0.2
• Adjust 4.12.1 -> 4.12.2
• Multidex support 1.0.2 -> 1.0.3

Analyzing CHANGELOGS is quite hard and cumbersome. I spent a half of hour on it doesn't point to one obvious issue.

After reviewing over and over I think it might be dependency bug. But I can not say for sure since we also did quite many changes in these two weeks.