我有一个偶尔崩溃的应用程序，我正在尝试调试原因。我已将调试信息添加到 logcat 中，其中包含对发生崩溃的库的所有调用，但不幸的是，上次发生崩溃时它发生在现场，当我拿到设备时，我可以查看 logcat唯一仍然存在的是堆栈跟踪。
我很难说出我的代码中发生崩溃的位置，并且正在寻找一些关于将堆栈跟踪号转换为（例如）我的代码中的行号的提示。
崩溃显然发生在“JavaBridge”中，前 17 帧（0-16）发生在我链接到的共享对象库“libsqlcipher.so”中。前 16 帧中的每一帧都只有一个地址，例如“#00 pc 0000000000088cf0”，但第 17 帧的名称是“_ZN9sqlcipher7compileEP7_JNIEnvP8_jobjectP7sqlite3P8_jstring+184”，我将其解释为该源文件中的“编译”函数，尽管我不是确定哪条线。第18帧是另一个地址，引用了我的项目目录下的“oat/arm64/base.odex”。我不确定为什么堆栈跟踪在这里结束，因为 compile() 不是由我的应用程序直接调用的。
这是完整的堆栈跟踪：
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)
显然，共享对象库中的帧不会有行号，但是如何从给定的地址中找到我自己的代码中发生崩溃的行？
更新：我用代码将每次调用都打包到 sqlcipher 库中，以便在调用继续之前记录有关对 SD 卡的调用的详细信息。几天后，下一次崩溃发生了，我很快发现......当崩溃发生时，这些呼叫都没有处于活动状态（超过 2 秒！）。
我还尝试在 Android Studio 中调试应用程序，试图了解上述数字对应的内容，但是...... Android Studio 没有列出每个堆栈帧的 PC，它甚至不会进入上面的本机代码与“强制步入”。