14

我通过 AirBrake.io 收到了一份没有符号化的崩溃报告。由于崩溃报告的格式与 Apple 崩溃日志的格式不完全相同,因此我不能像往常一样将其放在 XCode 上,因此我从 XCode 存档中获取了完全相同的构建,试图在命令行上对其进行符号化。结果如下:

$ atos -o kidsapp.app/kidsapp 0x0002fc4c
0x0002fc4c (in kidsapp)

我绝对确定我使用的是与崩溃报告相同的版本。所以我也尝试了 dwarfdump:

$ dwarfdump --lookup 0x0002fc4c --arch armv7 kidsapp.app.dSYM
----------------------------------------------------------------------
 File: kidsapp.app.dSYM/Contents/Resources/DWARF/kidsapp (armv7)
----------------------------------------------------------------------
Looking up address: 0x000000000002fc4c in .debug_info... not found.
Looking up address: 0x000000000002fc4c in .debug_frame... not found.

也没有结果。除了使用错误的 dSYM 文件之外,还有什么我可能做错的吗?我知道它是正确的,因为这是 AirBrake 的崩溃报告中提到的版本,它在我的 XCode 存档中。

欢迎任何想法/提示!

4

6 回答 6

29

我使用以下算法来计算它:

slide+ stack address- load address=symbol address

stack address是我从堆栈转储崩溃报告中获得的十六进制值(不是 .crash 文件,只是堆栈转储)。

slide是运行时 LC_SEGMENT cmd 的 vmaddr otool -arch armv7 -l APP_BINARY_PATH。我的通常最终是 0x00001000。

load address是复杂的部分。它实际上是主线程的最底部堆栈地址与运行时包含符号的二进制文件部分的第一个地址之间的差异dwarfdump --arch armv7 --all DSYM_BINARY_PATH。这只是main函数的符号地址。因此,如果您的最底部崩溃地址是 0x8000,而您的主函数的符号地址是 0x2000,那么您load address就是 0x6000。

现在有了所有这些部分,我可以计算符号地址并将其放入 atos 或 dwarfdump: dwarfdump --lookup SYM_ADDR --arch armv7 APP_BINARY_PATH

转储示例(您可以看到load address是 0x00003af4):

----------------------------------------------------------------------

文件:/Users/user/Desktop/MyApp.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp (armv7)

----------------------------------------------------------------------

0x00000024: [0x00003af4 - 0x00003b4e) 主要

0x00000098:[0x00003b50 - 0x00003d8c)-[MyAppDelegate 应用程序:didFinishLaunchingWithOptions:]

...垃圾场的其余部分

最困难的部分是意识到我包含的 2 个静态库之一在链接到我的应用程序二进制文件之前已经剥离了它们的符号!这留下了巨大的符号地址差距,所以我只得到了 dSYM 中所需符号的三分之二。

确保在您的静态库 xcode 项目中将以下标志设置为 NO,以便当您链接它时,您可以将符号拉入应用程序的二进制文件(稍后可以剥离):COPY_PHASE_STRIPDEAD_CODE_STRIPPINGSTRIP_INSTALLED_PRODUCT.

现在你可能会问,“如果堆栈转储不包含主函数,因为它不在主线程上,所以我无法获取主函数的堆栈地址,我该怎么办?”。对此我会回答,“我没有一个该死的线索!”。只需交叉手指,希望您可以获得包含符号地址的堆栈跟踪,或使用模仿 Apple 崩溃日志的崩溃报告系统,如 PLCrashReporter。

[编辑 2013 年 5 月 26 日] -

我注意到这load address实际上是 mach-o 二进制文件的地址。虽然我上面描述的通常可以工作 - 它实际上并不正确。这可以通过崩溃报告获得,但是这个答案的重点是在您没有崩溃报告时提供崩溃的符号。我弄清楚load address何时想要象征性的最好方法是确保我load address使用stack addresses.

我亲自创建了一个用于记录崩溃(不是崩溃报告)并将它们发送到 S3 存储桶的系统,以便稍后我可以检索它们以进行调试。当我启动我的应用程序时slide,如果我的应用程序崩溃load address并且main function address我发送一个stack addresses.

注意:dyld 函数使用#include <mach-o/dyld.h>

slide= 返回的地址_dyld_get_image_vmaddr_slide(0)

load address= 返回的地址_dyld_get_image_header(0)

main function address[NSThread callStackReturnAddresses]=在主线程上调用时的最后一个地址

在崩溃时,我肯定会记录[NSThread callStackReturnAddresses]以及[NSThread callStackSymbols]可以通过使用此方法检索的体系结构:

- (NSString*) arch
{
    NSString* arch =
#ifdef _ARM_ARCH_7
        @"armv7";
#elif defined (_ARM_ARCH_6)
        @"armv6";
#else
        nil;
#endif

    return arch;
}

不过,我还不知道如何区分 armv7 和 armv7s。

因此,这可能会在将来有所帮助。我计划把我学到的所有东西都变成一个简单的崩溃工具——比 natos 工具(可能是 natos v2)更好。

我已经更新了 natos 以支持load address手动提供:https ://github.com/NSProgrammer/natos

于 2012-09-17T17:55:03.140 回答
9

首先检查 dSYM 是否真的适合该应用程序:

dwarfdump --uuid kidsapp.app/kidsapp
dwarfdump --uuid kidsapp.app.dSYM

两者都应该返回相同的结果。

接下来检查 dSYM 是否有任何有效内容

dwarfdump --all kidsapp.app.dSYM

这应该至少提供一些信息,除了not found.

我猜 dSYM 已损坏。通常,您可能希望使用崩溃报告器,它为您提供包含所有线程和最后异常回溯信息的完整崩溃报告。我建议使用基于 PLCrashReporter 的东西,例如 QuincyKit(开源 SDK + 服务器 + Mac 上的符号)或 HockeyApp(开源 SDK + 付费服务 + 服务器端符号)(注意:我都是开发人员之一!)

于 2012-04-23T12:07:44.203 回答
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] [Relative Address] " path appName runtimeAddress relativeAddress
loadAddress=`echo "obase=16;ibase=10;$((runtimeAddress-relativeAddress))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $runtimeAddress -arch armv7

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

于 2015-01-14T16:36:17.713 回答
2

所以我的情况是:我从 NSException.callStackSymbols 中接收到崩溃字符串。

崩溃堆栈跟踪如下所示:

2   AppName                               0x00000001006c75b4 AppName + 2356660\r3   AppName                               0x00000001004f5cfc AppName + 449788\r4   UIKit                               0x000000018c0a8968 \u003credacted\u003e + 108\r5   UIKit      0x000000018c0a9328 \u003credacted\u003e + 28\r6   UIKit                               0x000000018beea250 \u003credacted\u003e + 1320\r7   UIKit                               0x000000018beede98 \u003credacted\u003e + 188\r8   UIKit                               0x000000018bcb5820 \u003credacted\u003e + 116\r9   UIKit                               0x000000018bbdec88 \u003credacted\u003e + 760\r10  UIKit                               0x000000018bbde610 \u003credacted\u003e + 312\r11  UIKit                               0x000000018bbde31c \u003credacted\u003e + 296\r12  UIKit                               0x000000018bbde3bc \u003credacted\u003e + 456\r13  QuartzCore                          0x0000000185b93b7c \u003credacted\u003e + 284\r14  libdispatch.dylib                   0x00000001811a8a2c \u003credacted\u003e + 16\r15  libdispatch.dylib                   0x00000001811b5654 \u003credacted\u003e + 1012\r16  CoreFoundation                      0x0000000181851650 \u003credacted\u003e + 12\r17  CoreFoundation                      0x000000018184f1a8 \u003credacted\u003e + 2272\r18  CoreFoundation                      0x000000018176f488 CFRunLoopRunSpecific + 552\r19  GraphicsServices                    0x0000000183735020 GSEventRunModal + 100\r20  UIKit         0x000000018bc09cc0 UIApplicationMain + 236\r21  AppName                               0x000000010048f714 AppName + 30484\r22  libdyld.dylib 0x000000018120dfc0 \u003credacted\u003e + 4

不要包含位码,因为 Apple 可以重新编译您的代码,并且您在 Organizer 中的存档中的 dsym 文件将不匹配。 在此处输入图像描述

运行这样的 bash 脚本:

#!/bin/bash
appName=AppName
runtimeAddress=0x00000001006c75b4
relativeAddress=2356660
loadAddress=`echo "obase=16;ibase=10;$((runtimeAddress-relativeAddress))" | bc`
atos -o $appName.app/$appName -l $loadAddress $runtimeAddress -arch arm64

假设您已经创建了一个 test.sh (touch test.sh)。如果由于权限问题而无法运行 sctipt (./test.sh):调用 chmod +x test.sh 现在 ./test.sh 应该可以工作了。并生成结果。

在此处输入图像描述

也可以使用 AppName.app.dSYM 文件来表示崩溃文件:

#!/bin/bash
appName=AppName
runtimeAddress=0x00000001006c75b4
relativeAddress=2356660
loadAddress=`echo "obase=16;ibase=10;$((runtimeAddress-relativeAddress))" | bc`
atos -o $appName.app.dSYM/Contents/Resources/DWARF/$appName -l $loadAddress $runtimeAddress -arch arm64
于 2018-04-11T12:35:38.690 回答
1

我认为这篇文章可能会对您有所帮助,https://stackoverflow.com/a/12559150/1773317。乔的承诺解决了我的问题。

原因是我的 .app 和 .dSYM 文件不能被聚光灯索引,所以我的 XCode 不能正确地表示崩溃信息。

于 2013-03-10T08:15:51.927 回答
1

您可以尝试使用我为符号化编写的脚本,使用atos命令:

https://github.com/IdoTene/MacosSymbolicateCrash

于 2018-02-11T09:04:57.290 回答