首页 > 代码库 > 解析UMeng的错误分析

解析UMeng的错误分析

2024-07-28 07:26:57   219人阅读

今天在友盟的错误分析里面找到了一个这样的错误：

Application received signal SIGSEGV(null)(	0   CoreFoundation                      0x2ef6dfeb  + 154	1   libobjc.A.dylib                     0x3971cccf objc_exception_throw + 38	2   CoreFoundation                      0x2ef6df15  + 0	3   appname                          0xcc979 appname + 821625	4   libsystem_platform.dylib            0x39d43f8b _sigtramp + 34	5   UIKit                               0x31842261  + 44	6   UIKit                               0x31842261  + 44	7   UIKit                               0x31842261  + 44	8   UIKit                               0x318ab1d9  + 256	9   UIKit                               0x3182d97f  + 142	10  UIKit                               0x318aaefd  + 128	11  UIKit                               0x31808115  + 312	12  UIKit                               0x31808407  + 106	13  UIKit                               0x31884c37  + 46	14  Foundation                          0x2f94d163 __NSFireDelayedPerform + 414	15  CoreFoundation                      0x2ef391b7  + 14	16  CoreFoundation                      0x2ef38dcf  + 782	17  CoreFoundation                      0x2ef3716b  + 1210	18  CoreFoundation                      0x2eea1f0f CFRunLoopRunSpecific + 522	19  CoreFoundation                      0x2eea1cf3 CFRunLoopRunInMode + 106	20  GraphicsServices                    0x33da6663 GSEventRunModal + 138	21  UIKit                               0x317ed16d UIApplicationMain + 1136	22  veryWallen                          0x85613 veryWallen + 529939	23  libdyld.dylib                       0x39c29ab7  + 2)dSYM UUID: 76634C55-B73F-303D-BA7C-511D5B84D45ACPU Type: armv7Slide Address: 0x00004000Binary Image: veryWallenBase Address: 0x0008b000
Application received signal SIGSEGV(null)
SIGSEGV和SIGBUS一般是因为访问已被释放的内存或者调用不存在的方法导致的，那么上面所说的崩溃信息基本就能定性为内存被释放啦？问题是在哪里崩溃的呢，完全不知道啊，所以只能往里找了。
使用showinfinder进入
/Users/username（电脑名）/Library/Developer/Xcode/Archives/这个文件夹，你会看到你打包时生成的xcarchive文件，当然你得用Archives来打包。
然后来查找正确的包吧，也就是崩溃程序的这个包的dSYM UUID必须和上面崩溃信息的一样。

打开终端，输入cd 然后拖进
xcarchive
文件吧，记得加上/dSYMs然后回车,这样你就进入了/dSYMs的目录了，再输入
dwarfdump --uuid appname.app.dSYM

命令，可别脑子坏掉的也输appname就成，然后你就能看到

armv7 和 armv7s的 两个UUID了，对比下就能知道是否是这个包了，不是就继续试直到找到位置


当你找到是哪个包了在来看下一步。。。

看看这句
	3   appname                          0xcc979 appname + 821625

 这就是崩溃时调用的地方，在终端继续输入

dwarfdump --arch=armv7 --lookup 0xcc979 对应的包的路径/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname


就会得出结果，如果你前面没有敲错，那么你应该能看到不一样的Log信息，不是么，

 看一下结果：发现有AT_name、Line table dir :、Line table file，没错，你能找到了出错的文件，是哪一行。。。

于是剩下的就靠你自己判断了。。。

 

今天到此为止！！！

还不明白看这个，我也是在紧跟前人的脚步
http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/

感谢先驱们，



解析UMeng的错误分析


联系
我们