常用开发工具🛠iOS

iOS 第三方dSYM定位BUG

2019-03-14  本文已影响5人  887d1fc86fe6

iOS 如何找到或生成 .dSYM 文件
系统崩溃日志或者手机奔溃日志

第三方日志包含:友盟日志,talkingdata日志....

我这里以 talkingdata日志 举例:

reason: -[NSTaggedPointerString stringValue]: unrecognized selector sent to instance 0xa000038363133355
callStackSymbols: (
    0   CoreFoundation                      0x000000018f2caff0 <redacted> + 148
    1   libobjc.A.dylib                     0x000000018dd2c538 objc_exception_throw + 56
    2   CoreFoundation                      0x000000018f2d1ef4 <redacted> + 0
    3   CoreFoundation                      0x000000018f2cef4c <redacted> + 916
    4   CoreFoundation                      0x000000018f1cad2c _CF_forwarding_prep_0 + 92
    5   XFKD                                0x000000010011e614 XFKD + 1074708 // 崩溃地址
    6   XFKD                                0x000000010011ed64 XFKD + 1076580 // 崩溃地址
    7   XFKD                                0x000000010011de2c XFKD + 1072684 // 崩溃地址
    8   libdispatch.dylib                   0x000000018e1829e0 <redacted> + 24
    9   libdispatch.dylib                   0x000000018e1829a0 <redacted> + 16
    10  libdispatch.dylib                   0x000000018e1910d4 <redacted> + 644
    11  libdispatch.dylib                   0x000000018e192a50 <redacted> + 540
    12  libdispatch.dylib                   0x000000018e1927d0 <redacted> + 124
    13  libsystem_pthread.dylib             0x000000018e38b1d0 _pthread_wqthread + 1096
    14  libsystem_pthread.dylib             0x000000018e38ad7c start_wqthread + 4
)

Process name: XFKD // App包名
dSYM UUID: B2707119-9ED6-35CB-B3B4-A9902B5CE8C0 // 当前 dSYM UUID
Architecture: arm64 // 当前的手机环境
Start Address: 0x100018000 // 起始地址
Slide Address: 0x18000 // 偏移地址

我们得到这个之后,那么久需要去找对应的. xcarchive文件,也就是你发布的时候留下的包,这个包的位置就在 Xcode->Window->Organizer,到了 Organizer 之后找到你对应的版本,也就是你这个BUG出现在哪个版本的包里,找到它之后 Show In Finder, 进入 . xcarchive 文件,在继续右键 显示包内容,找到:


0A020789-06B3-4E49-972F-B3E2B8F338D3.png

如果,你不能确定这个BUG是这个包产生的,那么可以通过比较 dSYM UUID 来确定:

BUG的 dSYM UUID :B2707119-9ED6-35CB-B3B4-A9902B5CE8C0 
BUG的 Architecture :arm64

我们可以将 xxxx.app.dSYM 文件拷贝出来放到一个新建的文件夹里面,这样方便我们操作。打开命令行工具 cd 到这个存放了 xxxx.app.dSYM 文件目录下,
比方我创建了一个 Test 文件夹存放 xxxx.app.dSYM, 那么我只需要 cd 到 Test 文件里面即可,好了,下一步我们打印这个 xxxx.app.dSYM 的 dSYM UUID,看看是否跟BUG的 dSYM UUID 是否一致

dwarfdump --uuid /Test/XFKD.app.dSYM

这行命令之后就会输入

UUID: F83F652E-4525-3052-A2E3-A74E7EC32E58 (armv7)
UUID: B2707119-9ED6-35CB-B3B4-A9902B5CE8C0 (arm64)

我们只需要比较BUG的 arm64 状态下的 UUID,那么它们是一致的。那么我们下面就开始来定位日志闪退位置。

atos -o XFKD.app.dSYM/Contents/Resources/DWARF/XFKD -arch arm64 -l 0x100018000 0x000000010011e614

其中 0x100018000:起始地址 0x000000010011e614:崩溃地址
崩溃地址一般为 崩溃信息中首行与你的App包名相关的地址 就是该例子中首行与 AppName 相关的地址信息(也就是崩溃信息中带有 XFKD 的567行)。
最后输出:

closure #1 in static KTTLog.insert(_:_:_:_:_:_:_:_:_:) (in XFKD) (KTTLog+Version.swift:30)

就是说crash的位置在 KTTLog+Version 文件中的 第30行。

最后我也还告诉一下大家在使用第三方工具定位日志的时候 dSYMTools 这个工具,不知道是不是我不会用还是使用有问题,我这边发现 dSYMTools 自己扫描出来的 dSYM UUID 始终无法跟正确的 xxxx.app.dSYM 文件里面或者是BUG的 dSYM UUID 对应上,也就是说工具上的 dSYM UUID 跟 文件或者BUG的 dSYM UUID 对应不上,就导致定位不了,很郁闷,不知道是不是我使用有问题,如果有会使用 dSYMTools 请告诉我下原因。

上一篇下一篇

猜你喜欢

热点阅读