ATOS和dwarfdump不会symbolicate我的地址ATOS和dwarfdump不会sym

-->

ATOS和dwarfdump不会symbolicate我的地址ATOS和dwarfdump不会sym

2019-05-13 14:53发布

站内文章 / 移动开发

86 0

迷人小祖宗

女 | 书童

私信

我收到通过AirBrake.io崩溃报告未symbolicated。由于崩溃报告是不完全相同的格式作为苹果系统崩溃日志我不能只是将其放在了XCode像往常一样，所以我把完全相同的构建从我的XCode存档试图symbolicate它的命令行。结果如下：

$ 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文件，我可以做错了吗？我知道这是正确的，因为这是在空气制动崩溃报告中所提到的版本，它在我的XCode存档。

任何想法/提示的欢迎！

Answer 1:

首先，检查的dSYM真的是正确的为应用程序：

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

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

如果拥有的dSYM任何有效内容下一步检查

dwarfdump --all kidsapp.app.dSYM

这应该给至少一些信息，除了not found 。

我想这将是的dSYM腐败。一般来说，你可能想使用一个崩溃报告，让您与所有线程和最后一个异常回溯信息的完整崩溃报告。我建议使用基于PLCrashReporter的东西，如QuincyKit（开源SDK +服务器+ symbolication在Mac）或HockeyApp（开源SDK +有偿服务+服务器端symbolication）（注：我的开发人员都一个）

Answer 2:

我用下面的算术弄明白：

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_STRIP ， DEAD_CODE_STRIPPING和STRIP_INSTALLED_PRODUCT 。

现在你可能会问：“我该怎么办，如果堆栈转储不包括主要功能，因为它不是在主线程，这样我不能让主函数的堆栈地址？”。对此，我会回答，“我不是一个受诅咒的线索！”。只需手指交叉，希望你可以得到一个堆栈跟踪包括符号地址或使用模仿苹果的崩溃日志，就像PLCrashReporter崩溃报告系统。

[编辑2013年5月26日，] -

它带给我的注意的是， load address是真正的Mach-O的二进制地址。虽然什么上述我经常可以工作 - 它实际上不是正确的。这可以通过崩溃报告来获得，但是这个答案的要点是提供了一种碰撞的符号，当你没有崩溃报告。我来搞清楚的最佳方式load address想symbolicate时是通过确保我的日志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区分虽然。

因此，这可能有助于在未来。我打算采取一切我已经学会并把这个变成一个简单的崩溃工具 - 比北约工具（可能是北约V2）更好。

我已经更新了北约支持供应load address手动： https://github.com/NSProgrammer/natos

Answer 3:

对他们来说，某些时候不具备这样的加载地址值：

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命令运行值。

Answer 4:

所以，我的情况：我收到崩溃串出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

不包括位码，因为苹果可以重新编译代码，并从主办单位存档将不匹配的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（触摸test.sh）。如果它无法运行，因为权限问题的sctipt（./test.sh）：呼叫使用chmod + X test.sh现在./test.sh应该工作。而产生的结果。

也有可能使用AppName.app.dSYM文件symbolicate崩溃文件：

#!/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