1
liuguangxuan 2023-02-18 11:40:59 +08:00 via Android
如果是第三方开源库的话,崩溃的可能性较小,可以在编译的时候链接上 asan ,然后跑一边排查一下问题。
|
2
xh3ccc 2023-02-18 11:42:13 +08:00 via iPhone
gdb 有 dir 命令可以添加新源码路径
|
3
changnet 2023-02-18 12:11:27 +08:00
0. 搜一下是否已知 bug
1. 如果是比较小的库,比如一个 lib ,编译一个 debug 版,拿 core 文件看数据 2. 如果是比较大的库,比如 libmysql 、glibc 这种,先考虑下调用方式是不是有问题或者版本是不是不对 3. 还排查不了,或者提个 issue 问一下更快些 4. 读源码,自己编译 debug 版去重现 |
4
FranzKafka95 2023-02-18 12:15:59 +08:00 via Android
如果有保留 symbol,addr2line 直接找源码对应的地方 debug
|
5
dearmymy 2023-02-18 12:17:06 +08:00
如果好复现就自己编译 debug 版本第三方库,会有 pdb 文件,配合 dump 文件,vs 附加可以很方便定位,
release 也有 pdb ,但是定位有时候不准。 |
6
MindMindMax 2023-02-18 12:22:40 +08:00
如果核心转储来自外部库,可以使用 addr2line 等工具来确定核心转储发生在哪里。该工具可以使用库的符号信息,如函数和变量名,来确定故障的确切位置。
如果有库的源代码,可以使用 gdb 或 Valgrind 等调试器来调试核心转储。有了这些符号和调试信息,就可以找到故障的确切位置并进行修复。 |
7
jones2000 2023-02-18 12:44:13 +08:00
源码编译出 pdb ,异常出 dump , 源码+pdb 就可以定位了。
|
8
kkkbbb OP 导致出 core 的原因好像是调用三方库接口,导致三方库接口出现 double free ,引起崩溃,产生的 core 文件
|
9
sjkdsfkkfd 2023-02-18 17:18:20 +08:00 via iPhone
有源码就自己编一一下呗,然后该咋定位咋定位
|
10
kkkbbb OP 谢谢各位!
|