xcode 强制symbolicatecrash 使用特定的.app 和.dSYM 文件？

Force symbolicatecrash to use a specific .app and .dSYM file?

提问by esilver

I have a .crash log from an ad-hoc version of my app that symbolicatecrash refuses to symbolicate. I have already applied the .patch to remove the 'die' commandin symbolicatecrash after apple broke the script in XCode 3.2.6. Symbolicatecrash has worked for other crash logs but refuses to symbolicate this one. My ad hoc app was built and is stored in "Archived Applications", so there is no reason why XCode shouldn't be able to find it. I have even copied the .app and .dSYM files right next to the .crash log, no dice.

我有一个来自我的应用程序的临时版本的 .crash 日志，symbolicatecrash 拒绝符号化。在苹果破坏了 XCode 3.2.6 中的脚本后，我已经应用了 .patch 来删除symbolicatecrash中的“die”命令。Symbolicatecrash 已经为其他崩溃日志工作过，但拒绝象征这个。我的临时应用程序已构建并存储在“存档应用程序”中，因此 XCode 没有理由无法找到它。我什至在 .crash 日志旁边复制了 .app 和 .dSYM 文件，没有骰子。

Is there a way I can force symobolicatecrash to use a specific .app and .dsym files even if it doesn't think it applies?

有没有办法强制 symobolicatecrash 使用特定的 .app 和 .dsym 文件，即使它认为它不适用？

回答by esilver

Turns out I accidentally deleted the build associated with the crash log. symbolicatecrash uses the following logic to figure out if there are symbols associated with a crash log:

原来我不小心删除了与崩溃日志相关的构建。symbolicatecrash 使用以下逻辑来确定是否有与崩溃日志相关的符号：

At the bottom of every crash log is a list of Binary Images. Yours is listed first. There is a guid associated with your binary image. For example:

每个崩溃日志的底部都有一个二进制图像列表。你的列在最前面。有一个与您的二进制图像相关联的 guid。例如：

0x1000 -   0x2befff +MyApp armv7  <a95274a309d73458a40cb5a6fd317a1c> /var/mobile/Applications/91884634-DA1A-4BDB-9E1E-6F487D8F25D7/MyApp.app/MyApp

The relevant guid is: a95274a309d73458a40cb5a6fd317a1c

相关的 guid 是：a95274a309d73458a40cb5a6fd317a1c

It next uses the tool mdfind, which looks at metadata associated with files in your file system, for the uppercase and hyphenated form of that GUID.

接下来它使用工具 mdfind，该工具查看与文件系统中文件关联的元数据，以获取该 GUID 的大写和连字符形式。

From your archived applications, if you click on MyApp.app.dSYM, then Get Info, then disclose More Info, you will see dSYM UUIDs and two GUIDs listed. The second GUID is the one that is relevant. It will be of the form:

从您存档的应用程序中，如果您单击 MyApp.app.dSYM，然后单击获取信息，然后披露更多信息，您将看到列出的 dSYM UUID 和两个 GUID。第二个 GUID 是相关的。它将采用以下形式：

A95274A3-09D7-3458-A40C-B5A6FD317A1C

A95274A3-09D7-3458-A40C-B5A6FD317A1C

Provided that the second GUID matches the guid in the .crash file, symbolicate crash will be able to find and symbolicate. If they don't match, it's the wrong binary.

如果第二个 GUID 与 .crash 文件中的 guid 匹配，symbolicate crash 将能够找到并进行符号化。如果它们不匹配，则是错误的二进制文件。

Cheers, Eric

干杯，埃里克

回答by esilver

OK turns out this answer is now what is required for the latest XCode 5.1.1:

好吧，这个答案现在是最新的 XCode 5.1.1 所需要的：

Recently I had a crash log from an ad-hoc build. XCode refused to Symbolicate. I had an archived build a few hours old and I wanted to force a symbolication using my archived build. Here is how I did it:

最近我有一个来自临时构建的崩溃日志。XCode 拒绝符号化。我有一个几个小时前的存档构建，我想使用我的存档构建强制进行符号化。这是我如何做到的：

1) First I opened a terminal window and went to the directory containing my archive. I ran this command:

1) 首先，我打开一个终端窗口并转到包含我的存档的目录。我运行了这个命令：

xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'

This pulled out the dsym_uuid of the archived build. The tr command converts the guid from an uppercase guid with dashes to a lowercase guid with no dashes

这提取了存档构建的 dsym_uuid。tr 命令将 guid 从带破折号的大写 guid 转换为不带破折号的小写 guid

2) I went into the .crash file and changed the guid associated with my binary in the crash log to the guid associated with the xcdarchive on my machine

2) 我进入 .crash 文件并将崩溃日志中与我的二进制文件关联的 guid 更改为与我机器上的 xcdarchive 关联的 guid

For example, went from

例如，从

   0x80000 -   0x49efff +MyApp armv7  <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp

to

到

   0x80000 -   0x49efff +MyApp armv7  <bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp

3) From the terminal, I set my DEVELOPER_DIR environment var to:

3）从终端，我将我的 DEVELOPER_DIR 环境变量设置为：

export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

4) Finally, I ran this beast of a command:

4）最后，我运行了这个命令：

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash -v MyApp.crash /Users/me/Library/Developer/Xcode/Archives/2013-05-31/MyApp\ 5-31-13\ 7.00\ PM.xcarchive/Products/Applications/MyApp.app

Note that the path to symbolicatecrash changes in newer versions of XCode, to:

请注意，在较新版本的 XCode 中，symbolicatecrash 的路径更改为：

 /Applications/Xcode6.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

This command run symbolicatecrash against your archive using the .crash file you have

此命令使用您拥有的 .crash 文件对您的存档运行symbolicatecrash

回答by Peter Johnson

A little additional information which may help.

一些可能有帮助的附加信息。

I have two UUIDs listed, and my first one matches the one in the crash log, not the second. However my crash comes from a device running ARM6, whereas the OPs came from one running ARM7

我列出了两个 UUID，我的第一个与崩溃日志中的一个匹配，而不是第二个。但是，我的崩溃来自运行 ARM6 的设备，而 OP 来自运行 ARM7 的设备

I therefore deduce that each UUID matches an architecture, if you build for ARM6 and ARM7 and the crash comes from a device running ARM6, then you'll need to match the first UUID, if it is running ARM7 you'll need the second.

因此，我推断每个 UUID 都匹配一个体系结构，如果您为 ARM6 和 ARM7 构建并且崩溃来自运行 ARM6 的设备，那么您需要匹配第一个 UUID，如果它运行 ARM7，您将需要第二个。

If you only have one UUID, I think you probably only built for one architecture.

如果您只有一个 UUID，我想您可能只为一种架构而构建。

This is mainly deduction, but seems likely.

这主要是推论，但似乎很有可能。

回答by esilver

There is a new process for extracting build UUIDs described here:

这里描述了一个用于提取构建 UUID 的新过程：

https://developer.apple.com/library/ios/qa/qa1765/_index.html

https://developer.apple.com/library/ios/qa/qa1765/_index.html

This is now the magical command to run to extract build UUID:

这是现在运行以提取构建 UUID 的神奇命令：

xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'

回答by Vlad

I have been able to force symbolicatecrash to symbolicate my crash log by overriding the dSYM UUID to the expected crashlog's UUID.

我已经能够通过将 dSYM UUID 覆盖为预期的崩溃日志的 UUID 来强制symbolicatecrash 符号化我的崩溃日志。

Put dsymand unsymbolicated.crashin same folder.

将dsym和unsymbolicated.crash放在同一个文件夹中。

Run ./symbolicatecrashin Verbose mode:

./symbolicatecrash以详细模式运行：

./symbolicatecrash unsymbolicated.crash > symbolicated.crash -d ./MyApp.app.dSYM/ -v 

Scroll to bottom and find the crashlog's expected UUID:

滚动到底部并找到崩溃日志的预期 UUID：

Did not find dsym for db3e90fa8b6d462c9d65049ab1f22ea4
-- [db3e90fa8b6d462c9d65049ab1f22ea4] NO MATCH (spotlight)

In Finder right click your .dsym file and click "Get Info" under "More Info" section header you will have the dSYM UUIDs: property. Copy this value to clipboard.

在 Finder 中，右键单击您的 .dsym 文件，然后单击“更多信息”部分标题下的“获取信息”，您将拥有 dSYM UUID：属性。将此值复制到剪贴板。

Using a hex editor (I used iHex from App Store) open MyApp.dysm/Contents/Resources/DWARF/MyAppand CMD+F the copied UUID.

使用十六进制编辑器（我使用 App Store 中的 iHex）打开MyApp.dysm/Contents/Resources/DWARF/MyApp并 CMD+F 复制的 UUID。

Replace this UUID with the expected expected one in this example I replaced it with: "db3e90fa8b6d462c9d65049ab1f22ea4".

将此 UUID 替换为本示例中预期的 UUID，我将其替换为："db3e90fa8b6d462c9d65049ab1f22ea4"。

NOTE: While this is exceptionally hacky and does not guarantee success and will more then likely result in mis-symbolicated crash with nonsensical method names but maybe it will work for you!

注意：虽然这非常hacky，并不能保证成功，并且更可能导致使用无意义方法名称的错误符号崩溃，但也许它对你有用！