How to debug Android crash when only a stack trace is available

Question

I've got an app that is occasionally crashing and I'm trying to debug why. I have added debug info to logcat wrapped around all calls to the library in which the crash is occurring but unfortunately the last time the crash occurred it was in the field and by the time I got the device gets to a place where I could view logcat the only thing still there was the stack trace.

I'm having a hard time telling where the crash occurred in my code and am looking for some tips on converting the stack trace numbers into (eg) line numbers in my code.

The crash apparently occurred in "JavaBridge" and the top 17 frames (0-16) occurred in a shared object library that I am linking to, "libsqlcipher.so". Each of the first 16 frames only has an address such as "#00 pc 0000000000088cf0 " but the 17th frame has a mangled name "_ZN9sqlcipher7compileEP7_JNIEnvP8_jobjectP7sqlite3P8_jstring+184" which I interpret to be the function "compile" in this source file although I'm not sure which line. The 18th frame is another address and references "oat/arm64/base.odex" under my project directory. I'm not sure why the stack trace ends here, because compile() isn't called directly by my app.

Here is the full stack trace:

07-16 10:40:03.103  2967  6420 F libc    : Fatal signal 7 (SIGBUS), code 2, fault addr 0x7007a1b000 in tid 6420 (JavaBridge)
07-16 10:40:03.229 15040 15040 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
07-16 10:40:03.229 15040 15040 F DEBUG   : Build fingerprint: 'google/angler/angler:7.1.2/NXGXXB/XXXXXXX:user/release-keys'
07-16 10:40:03.229 15040 15040 F DEBUG   : Revision: '0'
07-16 10:40:03.229 15040 15040 F DEBUG   : ABI: 'arm64'
07-16 10:40:03.230 15040 15040 F DEBUG   : pid: 2967, tid: 6420, name: JavaBridge  >>> com.michael.test <<<
07-16 10:40:03.230 15040 15040 F DEBUG   : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0x7007a1b000
07-16 10:40:03.230 15040 15040 F DEBUG   :     x0   290ccf38feaeb8f6  x1   0000000000000000  x2   0000006fdbbb0158  x3   0000000000000008
07-16 10:40:03.230 15040 15040 F DEBUG   :     x4   00000000000000a5  x5   0000000000000001  x6   0000000000000001  x7   0000007022acb074
07-16 10:40:03.230 15040 15040 F DEBUG   :     x8   0000000000000000  x9   0000000000000002  x10  0000000000000001  x11  0000000000000000
07-16 10:40:03.230 15040 15040 F DEBUG   :     x12  0000007004654640  x13  0000000000001a40  x14  000000000000000c  x15  0000000000000000
07-16 10:40:03.230 15040 15040 F DEBUG   :     x16  0000007007d714e8  x17  0000007022ac9464  x18  0000000000ffffeb  x19  0000007007a1b000
07-16 10:40:03.230 15040 15040 F DEBUG   :     x20  0000007007d71000  x21  00000070059057f4  x22  00000070059055f8  x23  0000006fdbd73788
07-16 10:40:03.230 15040 15040 F DEBUG   :     x24  0000007007ce1c60  x25  0000007007ce62c0  x26  0000000000000000  x27  0000007005905890
07-16 10:40:03.230 15040 15040 F DEBUG   :     x28  0000000000000000  x29  0000007005906df8  x30  0000007007b3236c
07-16 10:40:03.230 15040 15040 F DEBUG   :     sp   00000070059055c0  pc   0000007007afecf0  pstate 0000000080000000
07-16 10:40:03.249 15040 15040 F DEBUG   : 
07-16 10:40:03.249 15040 15040 F DEBUG   : backtrace:
07-16 10:40:03.249 15040 15040 F DEBUG   :     #00 pc 0000000000088cf0  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #01 pc 00000000000bc368  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #02 pc 00000000000bc9d8  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #03 pc 00000000000da90c  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #04 pc 00000000000de684  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #05 pc 000000000011c708  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #06 pc 000000000011c840  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #07 pc 000000000011d934  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #08 pc 000000000011e378  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #09 pc 0000000000093478  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #10 pc 0000000000093ab4  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #11 pc 00000000000efff4  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #12 pc 000000000010b070  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #13 pc 0000000000110bd8  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #14 pc 0000000000111090  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #15 pc 0000000000140eb0  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so
07-16 10:40:03.250 15040 15040 F DEBUG   :     #16 pc 00000000001481ec  /data/app/com.michael.test-1/lib/arm64/libsqlcipher.so (_ZN9sqlcipher7compileEP7_JNIEnvP8_jobjectP7sqlite3P8_jstring+184)
07-16 10:40:03.250 15040 15040 F DEBUG   :     #17 pc 000000000006482c  /data/app/com.michael.test-1/oat/arm64/base.odex (offset 0x53000)

Obviously the frames in the shared object library aren't going to have line numbers with them, but how, from the address given, can I find the line the crash occurred at in my own code?

Update: I wrapped every call into the sqlcipher library with code to log details about the call to the SD card before the call proceeded. After several days the next crash occurred, and I promptly found... that none of those calls were active (for over 2 seconds!) when the crash occurred.

I also tried debugging the application in Android Studio to try to get an idea what the above numbers correspond to, but... Android Studio does not list the PC of each stack frame, and it won't step into the native code above even with "Force Step Into".

Answer 1

You can investigate this crash which occurs in a shared native library using the ndk-stack tool. You need to point the tool to the directory where you have symbolic versions of your shared libraries. Then addresses get replaced automatically with the line numbers of your source files.