强制 symbolicatecrash 使用特定的 .app 和 .dSYM 文件？
我有一个来自我的应用程序的临时版本的 .crash 日志，symbolicatecrash 拒绝对其进行符号化。在苹果破坏脚本后，我已经应用.patch来删除symbolicatecrash中的“die”命令在 XCode 3.2.6 中。 Symbolicatecrash 已适用于其他崩溃日志，但拒绝对这一日志进行符号化。我的临时应用程序已构建并存储在“存档应用程序”中，因此 XCode 没有理由找不到它。我什至已经将 .app 和 .dSYM 文件复制到 .crash 日志旁边，没有骰子。
有没有办法强制 symobolicatecrash 使用特定的 .app 和 .dsym 文件，即使它认为它不适用？
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' command in 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.
Is there a way I can force symobolicatecrash to use a specific .app and .dsym files even if it doesn't think it applies?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
原来我不小心删除了与崩溃日志相关的构建。 symbolicatecrash 使用以下逻辑来确定是否存在与崩溃日志关联的符号：
每个崩溃日志的底部都有一个二进制映像列表。你的被列在最前面。有一个与您的二进制图像关联的指南。例如：
相关 GUID 为：a95274a309d73458a40cb5a6fd317a1c
接下来使用工具 mdfind，该工具查看与文件系统中的文件关联的元数据，以获取该 GUID 的大写和连字符形式。
在存档的应用程序中，如果单击 MyApp.app.dSYM，然后单击“获取信息”，然后公开“更多信息”，您将看到列出的 dSYM UUID 和两个 GUID。第二个 GUID 是相关的。其格式为：
A95274A3-09D7-3458-A40C-B5A6FD317A1C
前提是第二个 GUID 匹配.crash文件中的guid，symbolicate crash就能找到并symbolicate。如果它们不匹配，则二进制文件错误。
干杯，
埃里克
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:
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:
The relevant guid is: 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.
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:
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.
Cheers,
Eric
好吧，事实证明这个答案现在是最新的 XCode 5.1.1 所需要的：
最近我有一个来自临时构建的崩溃日志。 XCode 拒绝符号化。我有一个几个小时前的存档版本，我想使用我的存档版本强制进行符号化。我是这样做的：
1) 首先，我打开一个终端窗口，然后转到包含我的存档的目录。我运行了这个命令：
这提取了存档构建的 dsym_uuid。 tr 命令将 guid 从带破折号的大写 guid 转换为不带破折号的小写 guid
2) 我进入 .crash 文件并将崩溃日志中与我的二进制文件关联的 guid 更改为与我的计算机上的 xcdarchive 关联的 guid
例如，从
到
3) 从终端，我将 DEVELOPER_DIR 环境变量设置为：
4) 最后，我运行了这个命令的野兽：
请注意，路径对较新版本的 XCode 中的 symbolicatecrash 更改，至：
此命令使用您拥有的 .crash 文件对您的存档运行 symbolicatecrash
OK turns out this answer is now what is required for the latest 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:
1) First I opened a terminal window and went to the directory containing my archive. I ran this command:
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
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
For example, went from
to
3) From the terminal, I set my DEVELOPER_DIR environment var to:
4) Finally, I ran this beast of a command:
Note that the path to symbolicatecrash changes in newer versions of XCode, to:
This command run symbolicatecrash against your archive using the .crash file you have
一些可能有帮助的附加信息。
我列出了两个 UUID，第一个与崩溃日志中的 UUID 匹配，而不是第二个。然而，我的崩溃来自运行 ARM6 的设备，而 OP 来自运行 ARM7 的设备，
因此我推断每个 UUID 都与架构匹配，如果您为 ARM6 和 ARM7 构建并且崩溃来自运行 ARM6 的设备，那么您需要为了匹配第一个 UUID，如果它运行的是 ARM7，则需要第二个。
如果您只有一个 UUID，我认为您可能只为一种架构构建。
这主要是推论，但似乎有可能。
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
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.
If you only have one UUID, I think you probably only built for one architecture.
This is mainly deduction, but seems likely.
这里描述了一个提取构建 UUID 的新过程：
https://developer .apple.com/library/ios/qa/qa1765/_index.html
这是现在运行以提取构建 UUID 的神奇命令：
There is a new process for extracting build UUIDs described here:
https://developer.apple.com/library/ios/qa/qa1765/_index.html
This is now the magical command to run to extract build UUID:
我已经能够通过将 dSYM UUID 覆盖为预期崩溃日志的 UUID 来强制 symbolicatecrash 对我的崩溃日志进行符号化。
将 dsym 和 unsymbolicated.crash 放在同一文件夹中。
在详细模式下运行
./symbolicatecrash：滚动到底部并找到崩溃日志的预期 UUID：
在 Finder 中右键单击您的 .dsym 文件，然后单击“更多信息”部分标题下的“获取信息”，您将获得dSYM UUID：属性。将此值复制到剪贴板。
使用十六进制编辑器（我使用 App Store 中的 iHex）打开
MyApp.dysm/Contents/Resources/DWARF/MyApp并 CMD+F 复制的 UUID。将此 UUID 替换为预期的 UUID，在此示例中我将其替换为：
“db3e90fa8b6d462c9d65049ab1f22ea4”。注意：虽然这非常hacky并且不能保证成功，并且很可能会导致错误符号的崩溃和无意义的方法名称，但也许它会为你工作！
I have been able to force symbolicatecrash to symbolicate my crash log by overriding the dSYM UUID to the expected crashlog's UUID.
Put
dsymandunsymbolicated.crashin same folder.Run
./symbolicatecrashin Verbose mode:Scroll to bottom and find the crashlog's expected UUID:
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.
Using a hex editor (I used iHex from App Store) open
MyApp.dysm/Contents/Resources/DWARF/MyAppand CMD+F the copied UUID.Replace this UUID with the expected expected one in this example I replaced it with:
"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!