xcode 为什么我的崩溃报告没有符号化？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10707453/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why are my crash reports not symbolicated?
提问by Snowman
I'm using Xcode 4.3.1. The crash happened on my device, so I connect it and open up Organizer, go to my device logs, find the crash report, and here's what it reads:
我正在使用 Xcode 4.3.1。崩溃发生在我的设备上，所以我连接它并打开管理器，转到我的设备日志，找到崩溃报告，它是这样写的：
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x3514488f __exceptionPreprocess + 163
1 libobjc.A.dylib 0x3656b259 objc_exception_throw + 33
2 CoreFoundation 0x35144789 +[NSException raise:format:] + 1
3 CoreFoundation 0x351447ab +[NSException raise:format:] + 35
4 CoreFoundation 0x350b168b -[__NSCFDictionary setObject:forKey:] + 235
5 myapp 0x0015b4a7 0xe8000 + 472231
6 myapp 0x0018add1 0xe8000 + 667089
7 myapp 0x0013cd5b 0xe8000 + 347483
8 Foundation 0x30ffb60d __NSFireTimer + 145
9 CoreFoundation 0x35118a33 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 15
10 CoreFoundation 0x35118699 __CFRunLoopDoTimer + 365
11 CoreFoundation 0x3511726f __CFRunLoopRun + 1207
12 CoreFoundation 0x3509a4a5 CFRunLoopRunSpecific + 301
13 CoreFoundation 0x3509a36d CFRunLoopRunInMode + 105
14 GraphicsServices 0x36396439 GSEventRunModal + 137
15 UIKit 0x32190e7d UIApplicationMain + 1081
16 myapp 0x000f6aff 0xe8000 + 60159
17 myapp 0x000e9370 0xe8000 + 4976
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x34f3832c __pthread_kill + 8
1 libsystem_c.dylib 0x36e34208 pthread_kill + 48
2 libsystem_c.dylib 0x36e2d298 abort + 88
3 libc++abi.dylib 0x30af9f64 abort_message + 40
4 libc++abi.dylib 0x30af7346 _ZL17default_terminatev + 18
5 libobjc.A.dylib 0x3656b350 _objc_terminate + 140
6 libc++abi.dylib 0x30af73be _ZL19safe_handler_callerPFvvE + 70
7 libc++abi.dylib 0x30af744a std::terminate() + 14
8 libc++abi.dylib 0x30af881e __cxa_rethrow + 82
9 libobjc.A.dylib 0x3656b2a2 objc_exception_rethrow + 6
10 CoreFoundation 0x3509a506 CFRunLoopRunSpecific + 398
11 CoreFoundation 0x3509a366 CFRunLoopRunInMode + 98
12 GraphicsServices 0x36396432 GSEventRunModal + 130
13 UIKit 0x32190e76 UIApplicationMain + 1074
14 myapp 0x000f6af8 0xe8000 + 60152
15 myapp 0x000e9368 0xe8000 + 4968
I thought Xcode handles symbolicating the crash reports for me automatically? Why am I not getting any line numbers or methods? And why are my exception codes 0x00000000?
我认为 Xcode 会自动为我处理符号化崩溃报告？为什么我没有得到任何行号或方法？为什么我的异常代码是 0x00000000？
I tried the method found here, but when I type in any of the memory addresses, the output is just that same memory address. Is this the most information I can get out of the crash logs, or is something wrong here?
我尝试了这里找到的方法，但是当我输入任何内存地址时，输出就是相同的内存地址。这是我可以从崩溃日志中获得的最多信息，还是这里有问题？
采纳答案by Kerni
To symbolicate the crash report you need the dSYM package of that exact build. I guess this was a debug build that wasn't archived, so the dSYM also got overwritten the next time you build the app. This is why the organizer couldn't fully symbolicate the crash report.
要符号化崩溃报告，您需要该确切构建的 dSYM 包。我猜这是一个没有存档的调试版本，所以下次你构建应用程序时 dSYM 也会被覆盖。这就是为什么组织者不能完全象征性的崩溃报告。
The method you mentioned only works if the binary does not have symbols stripped, and even then it would not report the line numbers! So instead of using it against the app binary, rather use it with the dSYM. Maybe you are lucky and the new dSYM still has some helpful information.
您提到的方法仅在二进制文件没有剥离符号时才有效，即使这样它也不会报告行号！因此，与其将它用于应用程序二进制文件，不如将它与 dSYM 一起使用。也许你很幸运，新的 dSYM 仍然有一些有用的信息。
atos -arch armv7 -o 'appname.app.dSYM' 0x0015b4a7
atos -arch armv7 -o 'appname.app.dSYM' 0x0015b4a7
The crash itself could to be setting a NSDictionary value to e.g. a nil key.
崩溃本身可能是将 NSDictionary 值设置为例如 nil 键。
回答by ruxy
In the hopes that this might help someone else with the same issue, what worked for me was running the following command in the archive directory (looks like /Users/my_user/Library/Developer/Xcode/Archives/2012-09-24, so cd into there first)
希望这可以帮助其他有同样问题的人，对我有用的是在存档目录中运行以下命令（看起来像 /Users/my_user/Library/Developer/Xcode/Archives/2012-09-24，所以cd 首先进入那里）
mdimport .
Try running the symbolicatecrash script after that. In XCode, go to your Organizer, Device Logs, and select "Re-Symbolicate Log" by right clicking on the crash log.
之后尝试运行symbolicatecrash 脚本。在 XCode 中，转到您的管理器、设备日志，然后通过右键单击崩溃日志选择“重新符号化日志”。
回答by cshavit
I could not get XCode 4.5.1 to symbolicate by dragging the crash report into Organizer->Devices->Library->Device Logs.
我无法通过将崩溃报告拖到管理器-> 设备-> 库-> 设备日志中来获得 XCode 4.5.1 的符号化。
Nor could I obtain the symbolicated address of the crash by specifying the dSYMper the post above by @Kerni.
我也无法dSYM通过@Kerni指定上面的帖子来获得崩溃的符号地址。
I have used atos, but I could only get it to work by specifying the full path of the symbol file inside the xcarchivefile (actually it's a directory). Example:
我用过atos，但我只能通过在文件中指定符号文件的完整路径来让它工作xcarchive（实际上它是一个目录）。例子：
cd dir_where_the_xcarchive_is
atos -arch armv7 -o myApp\ 9-18-12\ 5.28\ PM.xcarchive/dSYMs/myApp.app.dSYM/Contents/Resources/DWARF/myApp 0x0001943a
回答by paiego
Regarding your question about the Exception Codes...
关于您关于异常代码的问题...
Exception Codes: 0x00000000, 0x00000000
... this Apple Technical NoteMight answer your question. In short, this crash report was not generated by a standard documented crash-type.
...这个 Apple 技术说明可能会回答您的问题。简而言之，此崩溃报告不是由标准记录的崩溃类型生成的。
About 16 lines into the crash log, you will see a line that starts with the text followed by one or more hexadecimal values, which are processor-specific codes that may give you more information on the nature of the crash. You may tell from these codes if the application crashed due to a programming error (for example, a bad memory access, an exception, etc), or if the application was terminated for some other reason, for example:
The exception code 0x8badf00dindicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. The exception code 0xbad22222indicates that a VoIP application has been terminated by iOS because it resumed too frequently. The exception code 0xdead10ccindicates that an applicaiton has been terminated by iOS because it held on to a system resource (like the address book database) while running in the background. The exception code 0xdeadfa11indicated that an application has been force quit by the user. Force quits occur when the user first holds down the On/Off button until "slide to power off" appears, then holds down the Home button. It's reasonable to assume that the user has done this because the application has become unresponsive, but it's not guaranteed - force quit will work on any application.
在崩溃日志中大约有 16 行，您将看到一行以文本开头，后跟一个或多个十六进制值，这些值是特定于处理器的代码，可以为您提供有关崩溃性质的更多信息。您可以通过这些代码判断应用程序是否由于编程错误（例如，内存访问错误、异常等）而崩溃，或者应用程序是否因其他原因终止，例如：
异常代码0x8badf00d表示应用程序已被 iOS 终止，因为发生了看门狗超时。应用程序启动、终止或响应系统事件的时间太长。造成这种情况的一个常见原因是在主线程上进行同步联网。异常代码0xbad22222表示 VoIP 应用程序已被 iOS 终止，因为它恢复过于频繁。异常代码0xdead10cc表示应用程序已被 iOS 终止，因为它在后台运行时保留了系统资源（如地址簿数据库）。异常代码0xdeadfa11表示应用程序已被用户强制退出。当用户首先按住开/关按钮直到出现“滑动以关闭电源”，然后按住主页按钮时，就会发生强制退出。假设用户这样做是合理的，因为应用程序变得没有响应，但不能保证 - 强制退出将适用于任何应用程序。
回答by bibo bode
Use Crashlyticsinstead.
请改用Crashlytics。
It provides instant (get notified through email) about real-time crash reports, and exact line # of where a crash occurred.
它提供有关实时崩溃报告的即时（通过电子邮件获得通知）以及崩溃发生位置的确切行号。
