iOS 崩溃报告：atos 未按预期工作

Posted 2023-03-06

【中文标题】iOS 崩溃报告：atos 未按预期工作

【英文标题】：iOS crash reports: atos not working as expected

【发布时间】：2012-11-26 23:25:19

【问题描述】：

我正在查看 Apple 提供的崩溃报告

Hardware Model:      iPhone4,1
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-11-18 16:03:44.951 -0600
OS Version:      ios 6.0.1 (10A523)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x352925b0 objc_msgSend + 16
1   MYAPP                           0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42
2   MYAPP                           0x0004fb26 -[MyImageTask didReceiveImage:] + 98
3   Foundation                      0x361ac8e8 __NSThreadPerformPerform
4   CoreFoundation                  0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
5   CoreFoundation                  0x3b37cee4 __CFRunLoopDoSources0
6   CoreFoundation                  0x3b37bcb2 __CFRunLoopRun
7   CoreFoundation                  0x3b2eeeb8 CFRunLoopRunSpecific
8   CoreFoundation                  0x3b2eed44 CFRunLoopRunInMode
9   GraphicsServices                0x396bc2e6 GSEventRunModal
10  UIKit                           0x3452e2f4 UIApplicationMain
11  MYAPP                           0x0004934a main + 70
12  MYAPP                           0x000492fc start + 36

有趣的是，当我使用 atos 查找对应于地址位置 0x0006573a 和 0x0004fb26 的代码行时，我得到了完全不同的匹配。 atos 输出甚至不是来自崩溃日志中提到的同一类（MyViewController、MyImageTask）。相反，atos 将我指向一个完全不相关的类中完全良性的代码行。我再次确认我正在使用我提交给 Apple 的确切 dSYM 和 IPA。

我的 atos 命令

/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26

与 /usr/bin/atos 和 armv7s 的结果相同。

还有其他人遇到过这个问题吗？你能给些建议么？谢谢。

【参考方案1】：

一个更简单的选择：您可以使用atos -l 标志让它为您计算。

假设您在崩溃日志中有以下要符号化的行：

5   MyApp                   0x0044e89a 0x29000 + 4348058

第一个十六进制数是堆栈地址，第二个十六进制数是加载地址。您可以忽略最后一个数字。您也不必担心幻灯片地址。

要进行符号化，请执行以下操作：

atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a

如果您找不到您的 MyApp.app/MyApp 文件，请将您的“.ipa”文件重命名为“.zip”，解压缩，它将位于 Payload 文件夹中。

如果您不确定要使用哪种架构（例如 armv7 或 armv7s），请滚动到崩溃文件的“二进制图像”部分，您可以在其中找到它。

干杯

【讨论】：

今天我在符号化来自 OS X 应用程序的 .crash 日志时遇到了很多麻烦——显然 Xcode 暂时不支持 OS X 应用程序的符号化，即使你有一个 .dSYM - 你的回答让我终于得到了一个崩溃的行号。谢谢！

有一点点错误 atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a

请注意，如果您的应用不包含调试符号，您可以将 -o 部分替换为 .dSYM 文件 (MyApp.app.dSYM/Contents/Resources/DWARF/MyApp) 中的符号

+后面的数字是十进制数，是stack address - load address的结果。所以你会发现第一个十六进制数是后两个数的和。

@chris 你是天才

【参考方案2】：

你必须计算地址来使用 atos，你不能只使用堆栈跟踪中的那个。

symbol address = slide + stack address - load address

slide 值是LC_SEGMENT cmd 中vmaddr 的值（大多数情况下是0x1000）。运行以下命令来获取它：

otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"

将ARCHITECTURE 替换为崩溃报告显示的实际架构，例如armv7。 将APP_BUNDLE/APP_EXECUTABLE 替换为实际可执行文件的路径。

stack address 是崩溃报告中的十六进制值。

load address 可以是在包含可执行文件的行最前面的Binary Images 部分中显示的第一个地址。 （通常是第一个条目）。

因为过去slide 的值等于load address 的值，所以这总是有效的。但由于 Apple 从 iOS 4.3 开始引入Address space layout randomization（有不同的变体），出于安全原因，应用加载地址是随机的。

【讨论】：

非常有帮助。谢谢你的解释。

但是我没有完全得到第三点。如果您能提及我在哪里可以找到二进制图像部分，那就太好了。

傻瓜，加载地址可以在崩溃报告中找到，Binary Images: 0x79000 - 0x206fff +MyApp armv7 /var/mobile/Applications/0709EF90-2F23-4220-AB2E-48BA4C983 /MyApp.app/MyApp

或者您可以使用atos -l 并让它为您计算。我也很确定“幻灯片”指的是标称加载地址和实际加载地址之间的差异，而不是加载地址本身。

@TimArnold 好吧，如果崩溃报告已经被符号化，那么地址已经被 Xcode 的符号化脚本规范化了。因此，请检查 stack address > load address 是否真的在检查二进制图像部分下的正确元素。

【参考方案3】：

只需使用 dwarfdump：

dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'

根本不需要做任何计算。

（来自Get symbol by address (symbolicating binary, iOS build)）。

【讨论】：

这仍然适用于 iOS 6–7 的崩溃日志吗？这就是我过去对 Mac 崩溃日志所做的事情，但它在 Lion 时代就停止了工作。

是的，我刚刚在 Mountain Lion 上的两个 iOS 6.1.3 崩溃报告中使用了它。

FWIW，dwarfdump 对我来说是一个 armv7s 拱门失败，而用 atos 做数学工作。

刚刚尝试使用 dwarfdump 然后按照@Kerni 的概述进行数学运算。数学工作 dwarfdump 没有，但与 Scott 一样，这是针对 armv7s 架构的。

【参考方案4】：

对于某些时间没有像这样的加载地址值的人：

Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
    0   CoreFoundation                      0x2c3084b7 <redacted> + 150
    1   libobjc.A.dylib                     0x39abec8b objc_exception_throw + 38
    2   CoreFoundation                      0x2c21cc35 CFRunLoopRemoveTimer + 0
    3   AppName                             0x0005a7db AppName + 272347  

我创建了一个简单的 bash 来帮助我调试：

#! /bin/bash
read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7

它只是读取应用程序的路径、应用程序名称、堆栈地址和“+”信号后的值（十进制值），然后找到加载地址的值来运行 atos 命令。

【讨论】：

此解决方案非常适用于 beta 测试人员（来自 Console.app）发送给我的未生成崩溃报告的异常。谢谢！