【问题标题】:iOS crash reports: atos not working as expectediOS 崩溃报告:atos 未按预期工作
【发布时间】:2012-11-14 12:36:06
【问题描述】:

我正在查看 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 查找对应于地址位置 0x0006573a0x0004fb26 的代码行时,我得到了完全不同的匹配。 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 的结果相同。

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

【问题讨论】:

    标签: iphone ios crash-reports symbolicatecrash symbolicate


    【解决方案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
    
    1. slide 值是LC_SEGMENT cmdvmaddr 的值(大部分是0x1000)。运行以下命令来获取它:

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

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

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

    3. 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-48BA4C983C /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)发送给我的未生成崩溃报告的异常。谢谢!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-04-12
    • 1970-01-01
    相关资源
    最近更新 更多