为什么我的崩溃报告没有象征意义? [英] Why are my crash reports not symbolicated?

查看:139
本文介绍了为什么我的崩溃报告没有象征意义?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用Xcode 4.3.1。崩溃发生在我的设备上,所以我连接它并打开管理器,转到我的设备日志,找到崩溃报告,这里是它的内容:

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:

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

我以为Xcode会自动为我设置崩溃报告?为什么我没有获得任何行号或方法?为什么我的异常代码为0x00000000?

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?

我试过此处找到的方法,但是当我键入任何内存地址时,输出就是相同的内存地址。这是我可以从崩溃日志中获取的最多信息,还是这里有问题?

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?

推荐答案

表示崩溃报告你需要那个精确构建的dSYM包。我猜这是一个未归档的调试版本,因此下次构建应用程序时dSYM也会被覆盖。这就是组织者无法完全表示崩溃报告的原因。

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.

您提到的方法只有在二进制文件没有剥离符号时才有效,即使这样也不会报告行号!因此,不要将其用于app二进制文件,而是将其与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.

atos -arch armv7 -o'appname.app.dSYM'0x0015b4a7

崩溃本身可以将NSDictionary值设置为例如没有钥匙。

The crash itself could to be setting a NSDictionary value to e.g. a nil key.

这篇关于为什么我的崩溃报告没有象征意义?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆