What the hell is this log?

In Android, What part of the stack trace from a native crash is important?

If you are an Android developer maybe your app gets crash and you face with some back stack trace in the Logcat that is very unordinary.

You always expect to see the stack of classes and find what lines are due to the crash, but I talk about the kind of log that you can’t see any class of your code. Something like below:

Image for post
Image for post
Example output for native crash

Crashes

An Android app crashes whenever there’s an unexpected exit caused by an unhandled exception or signal. An app that is written using Java crashes if it throws an unhandled exception, represented by the Throwable class. An app that is written using native-code languages crashes if there’s an unhandled signal, such as SIGSEGV, during its execution.

So there are two types of crashes in Android, Unhandled Exception (or java crash) and Signal (or native crash).
You are probably familiar with Logcat output in java crash. Where you can find a line that causes the crash and you can handle that. But we intend to talk about the native crash.

I am coding java not native

Maybe you say I am coding in java so why should I pay attention to native crash?

Okay, maybe you still not face this kind of crash but it’s not mean that this is not happening on java code. Maybe the reason that you still not see it is:
1- You are lucky
2- The Crashlytics tools like firebase can’t log these crashes.

here is the important point, the native crash is a signal from the kernel that stops application so no more code can run and everything will be stoped so crashlytics tools can’t log these crashes, But maybe you can see some of them on play store crashlytics section (because play store is outer service).

Diagnose the crashes

Image for post
Image for post
Photo by Online Marketing on Unsplash

If you coding native you must learn more about kinds of the native crash.
Here is the help page from the official ASOP website that explains all situations.

But if you coding java you will face with crashthe means so when this happens the process of application immediately will be aborted.

Image for post
Image for post
Example of SIGABRT log

Reading a stack trace

To introduce the different pieces in a crash dump, let’s work through this example crash dump from ASOP website. (I write this section only for who that want knows what meaning each part of the stack trace, you can skip this and read My Experience part.)

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Tombstone written to: /data/tombstones/tombstone_06
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

So let’s start investing in important parts.

Revision: '0'

The revision refers to the hardware rather than the software. This is usually unused but can be useful to help you automatically ignore bugs known to be caused by bad hardware.

ABI: 'arm'

The ABI is one of arm, arm64, mips, mips64, x86, or x86–64. These are the architecture of CPU

pid: 1656, tid: 1656, name: crasher >>> crasher <<<

This line identifies the specific thread in the process that crashed. In this case, it was the process’ main thread, so the process ID and thread ID match. The first name is the thread name, and the name surrounded by >>> and <<< is the process name. For an app, the process name is typically the fully-qualified package name (such as com.facebook.katana), which is useful when filing bugs or trying to find the app in Google Play. The pid and tid can also be useful in finding the relevant log lines preceding the crash.

signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

This line tells you which signal (SIGABRT) was received

Abort message: 'some_file.c:123: some_function: assertion "false" failed'

Abort Message is automatically gathered from the last line of fatal logcat output for this pid/tid, and in the case of a deliberate abort is likely to give an explanation of why the program killed itself.

r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010

The register dump shows the content of the CPU registers at the time the signal was received.

backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher

The backtrace shows you where in the code we were at the time of crash. The first column is the frame number. The PC values are relative to the location of the shared library rather than absolute addresses. The next column is the name of the mapped region.


My Experience

I was faced with the native crash in two situations.

Application Not Responding (ANR)

If you do a large task in the main thread (UI thread) the application not responding so the kernel decides to abort the process.

In this situation the back stack trace looks like this:

native: pc 000000000007a6c4  /system/lib64/libc.so (tgkill+8)
native: pc 0000000000077920 /system/lib64/libc.so (pthread_kill+64)
native: pc 000000000002538c /system/lib64/libc.so (raise+24)
native: pc 000000000001d24c /system/lib64/libc.so (abort+52)
native: pc 000000000001225c /system/lib64/libcutils.so (__android_log_assert+224)
native: pc 00000000000610e0 /system/lib64/libhwui.so
native: pc 000000000003908c /system/lib64/libhwui.so
native: pc 000000000003609c /system/lib64/libhwui.so
native: pc 000000000003b4fc /system/lib64/libhwui.so
native: pc 000000000003c520 /system/lib64/libhwui.so
native: pc 000000000003e694 /system/lib64/libhwui.so ()
native: pc 00000000000127f0 /system/lib64/libutils.so (_ZN7android6Thread11_threadLoopEPv+336)
native: pc 00000000000a50b0 /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+116)
native: pc 00000000000770f4 /system/lib64/libc.so (_ZL15__pthread_startPv+204)
native: pc 000000000001e7d0 /system/lib64/libc.so (__start_thread+16)

Below you can see theThis is the library for rendering UI.
So if you see in back stack trace it means you have ANR in your app.

Use Reflection

In my case, once I used the reflection in a for loop I get the native crash for Android Oreo+. In this situation the back stack trace looks like this:

#00 pc 000000000006990c  /system/lib64/libc.so (tgkill+8)
#01 pc 000000000001dc50 /system/lib64/libc.so (abort+88)
#02 pc 0000000000437c9c /system/lib64/libart.so (_ZN3art7Runtime5AbortEPKc+528)
#03 pc 00000000004383ac /system/lib64/libart.so (_ZN3art7Runtime7AborterEPKc+24)
#04 pc 0000000000522ab4 /system/lib64/libart.so (_ZN7android4base10LogMessageD1Ev+900)
#05 pc 00000000001d3cf8 /system/lib64/libart.so (_ZN3art2gc9collector17ConcurrentCopying11FinishPhaseEv+564)
#06 pc 00000000001d2618 /system/lib64/libart.so (_ZN3art2gc9collector17ConcurrentCopying9RunPhasesEv+1528)
#07 pc 00000000001e63ec /system/lib64/libart.so (_ZN3art2gc9collector16GarbageCollector3RunENS0_7GcCauseEb+352)
#08 pc 000000000020a578 /system/lib64/libart.so (_ZN3art2gc4Heap22CollectGarbageInternalENS0_9collector6GcTypeENS0_7GcCauseEb+3632)

Below you can see Art is the java virtual machine for Android.
So if you seetake care that you don’t use reflection.
It doesn’t mean every is about reflection just as my experience is a candidate for debugging.

Thank you for reading my article. Share your native crash experience with us to help other ones.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store