标签：libc arm protobuf log const NPU creat 标准 oid
一、需求分析
so 的崩溃并不像 Java 代码那么好定位，我们通常看到的就只是 so 中的一大段崩溃的堆栈信息。那么我们怎么通过这个堆栈信息来定位我们的问题呢？
二、addr2line
1. 介绍
Addr2line 工具（它是标准的 GNU Binutils 中的一部分）是一个可以将指令的地址和可执行映像转换成文件名、函数名和源代码行数的工具。
一般适用于 debug 版本或带有 symbol 信息的库。
2. 工具位置
我们下载的 NDK 里面已经默认有了这个工具，对应的路径如下，其中 .. 表示你的 NDK 安装的路径（每个人的可能都不一样）
Windows：
32位：..\ndk-bundle\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-addr2line.exe
64位：..\ndk-bundle\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin\aarch64-linux-android-addr2line.exe
Linux：
32位：../android-ndk-r16b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-addr2line
64位：../android-ndk-r16b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-addr2line
当然我们也可以把这个路径配置到环境变量中去。
3. 指令释义
4. 使用示例
5. 实际应用
例如出现了如下崩溃：
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4d42d8b4 r0 ead025fc r1 ead025f0 r2 ead025fd r3 4d42d8a4 r4 efba899c r5 ead025fc r6 ead0263c r7 efba8984 r8 ead00000 r9 ead00000 sl ead025fc fp 00000001 ip 00000000 sp ee5ff348 lr 0007ffff pc efb5e15e cpsr 800f0030 backtrace: #00 pc 0005915e /system/lib/libc.so (arena_dalloc_bin_locked_impl+345) #01 pc 00058ffd /system/lib/libc.so (je_arena_dalloc_bin_junked_locked+12) #02 pc 0007ae27 /system/lib/libc.so (je_tcache_bin_flush_small+366) #03 pc 0007ac5b /system/lib/libc.so (je_tcache_event_hard+58) #04 pc 0006a505 /system/lib/libc.so (je_malloc+636) #05 pc 00339c7f /vendor/lib/libstfaceunlock.so #06 pc 00282064 /vendor/lib/libstfaceunlock.so #07 pc 001fc094 /vendor/lib/libstfaceunlock.so #08 pc 002056b0 /vendor/lib/libstfaceunlock.so #09 pc 002809d8 /vendor/lib/libstfaceunlock.so #10 pc 00103f58 /vendor/lib/libstfaceunlock.so #11 pc 00105398 /vendor/lib/libstfaceunlock.so #12 pc 001062c4 /vendor/lib/libstfaceunlock.so #13 pc 000a4f14 /vendor/lib/libstfaceunlock.so #14 pc 0007957c /vendor/lib/libstfaceunlock.so #15 pc 00023d2c /vendor/lib/libstfaceunlock.so (cv_face_create_tracker+424)
我们就可以把每个段地址翻译成具体的代码：
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4d42d8b4 r0 ead025fc r1 ead025f0 r2 ead025fd r3 4d42d8a4 r4 efba899c r5 ead025fc r6 ead0263c r7 efba8984 r8 ead00000 r9 ead00000 sl ead025fc fp 00000001 ip 00000000 sp ee5ff348 lr 0007ffff pc efb5e15e cpsr 800f0030 backtrace: #00 pc 0005915e /system/lib/libc.so (arena_dalloc_bin_locked_impl+345) #01 pc 00058ffd /system/lib/libc.so (je_arena_dalloc_bin_junked_locked+12) #02 pc 0007ae27 /system/lib/libc.so (je_tcache_bin_flush_small+366) #03 pc 0007ac5b /system/lib/libc.so (je_tcache_event_hard+58) #04 pc 0006a505 /system/lib/libc.so (je_malloc+636) #05 pc 00339c7f /vendor/lib/libstfaceunlock.so --> /usr/local/google/buildbot/src/android/master-ndk/toolchain/gcc/gcc-4.9/libstdc++-v3/libsupc++/new_op.cc:56 #06 pc 00282064 /vendor/lib/libstfaceunlock.so --> google::protobuf::internal::StringTypeHandlerBase::New() #07 pc 001fc094 /vendor/lib/libstfaceunlock.so --> caffe::LayerParameter::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*) #08 pc 002056b0 /vendor/lib/libstfaceunlock.so --> caffe::NetParameter::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*) #09 pc 002809d8 /vendor/lib/libstfaceunlock.so --> google::protobuf::MessageLite::ParseFromCodedStream(google::protobuf::io::CodedInputStream*) #10 pc 00103f58 /vendor/lib/libstfaceunlock.so --> ReadProtoFromBinaryResource(protector::ModelResource&, google::protobuf::MessageLite*) #11 pc 00105398 /vendor/lib/libstfaceunlock.so --> protector::CaffeModel::Init(protector::TarModelResource&, std::string const&, protector::NetConfig, bool #12 pc 001062c4 /vendor/lib/libstfaceunlock.so --> protector::ModelLoader::LoadByName(std::string const&, bool) const #13 pc 000a4f14 /vendor/lib/libstfaceunlock.so --> stsdk::detection::DetectorHunter::Init(protector::ModelLoader&) #14 pc 0007957c /vendor/lib/libstfaceunlock.so --> __appProtect_cv_common_detection_hunter_create_start #15 pc 00023d2c /vendor/lib/libstfaceunlock.so (cv_face_create_tracker+424)
三、objdump
1. 介绍
objdump 是 gcc 工具，用来查看编译后目标文件的组成。
2. 工具位置
我们下载的 NDK 里面同样默认有了这个工具，对应的路径如下，其中 .. 表示你的 NDK 安装的路径（每个人的可能都不一样）
Windows：
32位：..\ndk-bundle\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-objdump.exe
64位：..\ndk-bundle\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin\aarch64-linux-android-objdump.exe
Linux：
32位：../android-ndk-r16b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objdump
64位：../android-ndk-r16b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-objdump
当然我们也可以把这个路径配置到环境变量中去。
3. 指令释义
4. 使用示例
通常我们会把输出重定向到一个文本文件中去，使用语法如下：
arm-linux-androideabi-objdump -d 库文件 > 输出文件
打开文件，查看汇编执行顺序，找到 23098 地址段
通过 backtrace 地址里的汇编段和偏移量在上面的汇编顺序里找到对应汇编命令
这里的方法名不容易看懂，可以使用 c++filt 命令找到实际的代码段可以更方面定位代码
然后找到具体的代码
判断是在 gen_statistics 函数之前，所以增加非空判断
?
其它：
————————————————
版权声明：本文为CSDN博主「阿飞__」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/afei__/article/details/81181827
so 动态库崩溃问题定位（addr2line与objdump）
标签：libc arm protobuf log const NPU creat 标准 oid
原文地址：https://www.cnblogs.com/yipianchuyun/p/13130155.html
