如何从导致 android 本机崩溃的第 3 方共享库中找到指令？
How to find instruction from 3rd party shared library that caused an android native crash?
我在我的开发者控制台中发现我正在使用的第 3 方共享库发生崩溃。
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Sony/D2406/D2406:4.4.4/18.3.1.C.1.17/7nt3bg:user/release-keys'
Revision: '0'
pid: 6736, tid: 6794, name: Main Thread >>> com.mytest.app <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000012
r0 00000000 r1 64c3b3f4 r2 00000001 r3 00000000
r4 ffffb194 r5 64bb9660 r6 64c3b3f4 r7 64c3d848
r8 ffffbb78 r9 ffffb214 sl 64d92bcc fp 64d93bd4
ip 64bbb3ac sp 64d92bc0 lr 641c029f pc 641c02f8 cpsr 40070030
d0 0000000700000007 d1 4000000040000000
d2 000000003f47ae40 d3 0000000000000000
d4 fe8000003f000001 d5 000122e800000000
d6 0000000000000000 d7 00000000000022ec
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 3f14f8b588e30000 d17 c01dc3a2163fdd66
d18 3f8000003f800000 d19 0000000100000000
d20 0000000700000001 d21 000000004036ee50
d22 0000000064d94b04 d23 403294d140368de8
d24 3f80000000000000 d25 3f8000003f800000
d26 c0000000c0000000 d27 0000000000000000
d28 0000000000000000 d29 3f80000000000000
d30 0000000000000000 d31 0000000000000000
scr 6000009f
backtrace:
#00 pc 001452f8 /data/app-lib/com.mytest.app-1/libcode.so
#01 pc 0014529b /data/app-lib/com.mytest.app-1/libcode.so
code around pc:
641c02d8 f8da6048 b11005cc 68496801 f8df4788
641c02e8 22015a9c 4a98f8df 447d2300 68005960
641c02f8 1012f9b0 50e4f20d e5fcf544 1005f859
641c0308 68896848 d00c4288 d0192800 51e4f20d
641c0318 e61af544 0a6cf8df f8594478 68400000
641c0328 f8dfe00f 44780a64 0000f859 51e4f20d
641c0338 e110f54e 4604e00c 05e0f8da ba38f00b
641c0348 f8df2000 30141a48 f8594479 60481001
641c0358 05e0f8da 6801b110 47886849 5a30f8df
641c0368 23012201 5960447d f9b06800 f50d1012
641c0378 f54460bf f859e5c0 68481005 42886889
641c0388 2800d00c f50dd019 f54461bf f8dfe5de
641c0398 44780a04 0000f859 e00f6840 09f8f8df
641c03a8 f8594478 f50d0000 f54e61bf e00ce0d4
641c03b8 f8da4604 f00b05f4 2000b9fb 19dcf8df
641c03c8 44793014 1001f859 f8da6048 b11005f4
code around lr:
641c027c f50d7901 f54460ba f859e63c 68481005
641c028c 42886889 2800d00c f50dd019 f54461ba
641c029c f8dfe65a 44780ad8 0000f859 e00f6840
641c02ac 0accf8df f8594478 f50d0000 f54e61ba
641c02bc e00ce150 f8da4604 f00b05cc 2000ba77
641c02cc 1ab0f8df 44793014 1001f859 f8da6048
641c02dc b11005cc 68496801 f8df4788 22015a9c
641c02ec 4a98f8df 447d2300 68005960 1012f9b0
641c02fc 50e4f20d e5fcf544 1005f859 68896848
641c030c d00c4288 d0192800 51e4f20d e61af544
641c031c 0a6cf8df f8594478 68400000 f8dfe00f
641c032c 44780a64 0000f859 51e4f20d e110f54e
641c033c 4604e00c 05e0f8da ba38f00b f8df2000
641c034c 30141a48 f8594479 60481001 05e0f8da
641c035c 6801b110 47886849 5a30f8df 23012201
641c036c 5960447d f9b06800 f50d1012 f54460bf
该库适用于 arm-v7 abi。当我使用 (arm-linux-androideabi-objdump.exe) 反编译共享库或 objdump 时，是否有可能找出导致崩溃的指令，在那里我可以看到导出的方法和指令。我如何将故障转储中的 pc 地址与指令相关联。我没有权限访问源代码，只有 so 文件。
可能吗？当然，只需反汇编 .so 文件即可。计算运行时加载地址与 ELF 中的默认地址通常可能需要花些功夫，但这里的转储显示 641c02f8，你得到了有用的回溯 "pc 001452f8"，这意味着6407b000 的负载偏移并省去麻烦。
当然，如果做不到这一点，您还会在那里转储有问题的代码！将其压缩回原始二进制文件并强制通过反汇编程序并不需要太多努力，因此：
Disassembly of section .data:
00000000 <.data>:
...
2d8: 6048 str r0, [r1, #4]
2da: f8da 05cc ldr.w r0, [sl, #1484] ; 0x5cc
2de: b110 cbz r0, 0x2e6
2e0: 6801 ldr r1, [r0, #0]
2e2: 6849 ldr r1, [r1, #4]
2e4: 4788 blx r1
2e6: f8df 5a9c ldr.w r5, [pc, #2716] ; 0xd84
2ea: 2201 movs r2, #1
2ec: f8df 4a98 ldr.w r4, [pc, #2712] ; 0xd88
2f0: 2300 movs r3, #0
2f2: 447d add r5, pc
2f4: 5960 ldr r0, [r4, r5]
2f6: 6800 ldr r0, [r0, #0]
2f8: f9b0 1012 ldrsh.w r1, [r0, #18]
（我截断了地址以避免出现可笑的 1.6GB 二进制文件）
从外观上看，它正在追踪几个指针以找到一些结构，从中加载带符号的 16 位值，但它找到的结构指针 (r0) 显然是 NULL。
我在我的开发者控制台中发现我正在使用的第 3 方共享库发生崩溃。
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Sony/D2406/D2406:4.4.4/18.3.1.C.1.17/7nt3bg:user/release-keys'
Revision: '0'
pid: 6736, tid: 6794, name: Main Thread >>> com.mytest.app <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000012
r0 00000000 r1 64c3b3f4 r2 00000001 r3 00000000
r4 ffffb194 r5 64bb9660 r6 64c3b3f4 r7 64c3d848
r8 ffffbb78 r9 ffffb214 sl 64d92bcc fp 64d93bd4
ip 64bbb3ac sp 64d92bc0 lr 641c029f pc 641c02f8 cpsr 40070030
d0 0000000700000007 d1 4000000040000000
d2 000000003f47ae40 d3 0000000000000000
d4 fe8000003f000001 d5 000122e800000000
d6 0000000000000000 d7 00000000000022ec
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 3f14f8b588e30000 d17 c01dc3a2163fdd66
d18 3f8000003f800000 d19 0000000100000000
d20 0000000700000001 d21 000000004036ee50
d22 0000000064d94b04 d23 403294d140368de8
d24 3f80000000000000 d25 3f8000003f800000
d26 c0000000c0000000 d27 0000000000000000
d28 0000000000000000 d29 3f80000000000000
d30 0000000000000000 d31 0000000000000000
scr 6000009f
backtrace:
#00 pc 001452f8 /data/app-lib/com.mytest.app-1/libcode.so
#01 pc 0014529b /data/app-lib/com.mytest.app-1/libcode.so
code around pc:
641c02d8 f8da6048 b11005cc 68496801 f8df4788
641c02e8 22015a9c 4a98f8df 447d2300 68005960
641c02f8 1012f9b0 50e4f20d e5fcf544 1005f859
641c0308 68896848 d00c4288 d0192800 51e4f20d
641c0318 e61af544 0a6cf8df f8594478 68400000
641c0328 f8dfe00f 44780a64 0000f859 51e4f20d
641c0338 e110f54e 4604e00c 05e0f8da ba38f00b
641c0348 f8df2000 30141a48 f8594479 60481001
641c0358 05e0f8da 6801b110 47886849 5a30f8df
641c0368 23012201 5960447d f9b06800 f50d1012
641c0378 f54460bf f859e5c0 68481005 42886889
641c0388 2800d00c f50dd019 f54461bf f8dfe5de
641c0398 44780a04 0000f859 e00f6840 09f8f8df
641c03a8 f8594478 f50d0000 f54e61bf e00ce0d4
641c03b8 f8da4604 f00b05f4 2000b9fb 19dcf8df
641c03c8 44793014 1001f859 f8da6048 b11005f4
code around lr:
641c027c f50d7901 f54460ba f859e63c 68481005
641c028c 42886889 2800d00c f50dd019 f54461ba
641c029c f8dfe65a 44780ad8 0000f859 e00f6840
641c02ac 0accf8df f8594478 f50d0000 f54e61ba
641c02bc e00ce150 f8da4604 f00b05cc 2000ba77
641c02cc 1ab0f8df 44793014 1001f859 f8da6048
641c02dc b11005cc 68496801 f8df4788 22015a9c
641c02ec 4a98f8df 447d2300 68005960 1012f9b0
641c02fc 50e4f20d e5fcf544 1005f859 68896848
641c030c d00c4288 d0192800 51e4f20d e61af544
641c031c 0a6cf8df f8594478 68400000 f8dfe00f
641c032c 44780a64 0000f859 51e4f20d e110f54e
641c033c 4604e00c 05e0f8da ba38f00b f8df2000
641c034c 30141a48 f8594479 60481001 05e0f8da
641c035c 6801b110 47886849 5a30f8df 23012201
641c036c 5960447d f9b06800 f50d1012 f54460bf
该库适用于 arm-v7 abi。当我使用 (arm-linux-androideabi-objdump.exe) 反编译共享库或 objdump 时，是否有可能找出导致崩溃的指令，在那里我可以看到导出的方法和指令。我如何将故障转储中的 pc 地址与指令相关联。我没有权限访问源代码，只有 so 文件。
可能吗？当然，只需反汇编 .so 文件即可。计算运行时加载地址与 ELF 中的默认地址通常可能需要花些功夫，但这里的转储显示 641c02f8，你得到了有用的回溯 "pc 001452f8"，这意味着6407b000 的负载偏移并省去麻烦。
当然，如果做不到这一点，您还会在那里转储有问题的代码！将其压缩回原始二进制文件并强制通过反汇编程序并不需要太多努力，因此：
Disassembly of section .data:
00000000 <.data>:
...
2d8: 6048 str r0, [r1, #4]
2da: f8da 05cc ldr.w r0, [sl, #1484] ; 0x5cc
2de: b110 cbz r0, 0x2e6
2e0: 6801 ldr r1, [r0, #0]
2e2: 6849 ldr r1, [r1, #4]
2e4: 4788 blx r1
2e6: f8df 5a9c ldr.w r5, [pc, #2716] ; 0xd84
2ea: 2201 movs r2, #1
2ec: f8df 4a98 ldr.w r4, [pc, #2712] ; 0xd88
2f0: 2300 movs r3, #0
2f2: 447d add r5, pc
2f4: 5960 ldr r0, [r4, r5]
2f6: 6800 ldr r0, [r0, #0]
2f8: f9b0 1012 ldrsh.w r1, [r0, #18]
（我截断了地址以避免出现可笑的 1.6GB 二进制文件）
从外观上看，它正在追踪几个指针以找到一些结构，从中加载带符号的 16 位值，但它找到的结构指针 (r0) 显然是 NULL。