如果
使用 symbolicatecrash 解析崩溃堆栈 不起作用,可以通过以下方式看看符号文件和堆栈是否是对应的:
dwarfdump --uuid xxx.app
dwarfdump --uuid xxx.app.dSYM
grep "0x.*com.wihing.xxx .*<" NoSymbolsTestxxx.crash
如果输出一样的uuid,那么就是对应的,此时symbolicatecrash应该可以正常解析符号。
如果不一样,那么说明崩溃堆栈和符号文件对应不上,很可能是搞错版本,或者打包的时候有问题导致符号文件生成不正确。
就算如此,我们还是可以尝试解析一下,通过一下几种方法:
使用atos:
atos -arch armv7 -o [BinaryFile or dSYMFile] 0x431b
使用gdb:
gdb appname.app.dSYM/Contents/Resources/DWARF/appname
info line 0x431b
使用dwarfdump:
dwarfdump --lookup 0x431b --arch armv7 APP_BINARY_PATH
以上使用的符号解析工具涉及到的地址,都是可执行文件上
dwarfdump --uuid xxx.app
dwarfdump --uuid xxx.app.dSYM
grep "0x.*com.wihing.xxx .*<" NoSymbolsTestxxx.crash
如果输出一样的uuid,那么就是对应的,此时symbolicatecrash应该可以正常解析符号。
如果不一样,那么说明崩溃堆栈和符号文件对应不上,很可能是搞错版本,或者打包的时候有问题导致符号文件生成不正确。
就算如此,我们还是可以尝试解析一下,通过一下几种方法:
使用atos:
atos -arch armv7 -o [BinaryFile or dSYMFile] 0x431b
使用gdb:
gdb appname.app.dSYM/Contents/Resources/DWARF/appname
info line 0x431b
使用dwarfdump:
dwarfdump --lookup 0x431b --arch armv7 APP_BINARY_PATH
以上使用的符号解析工具涉及到的地址,都是可执行文件上