【问题标题】:Stack trace method names redacted堆栈跟踪方法名称已编辑
【发布时间】:2012-10-31 10:58:11
【问题描述】:

当我的应用在他们的设备上崩溃时,我有用户通过电子邮件向我发送堆栈跟踪信息。在 iOS 6 之前,它们看起来像这样:

CRASH: NSInvalidArgumentException (*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil)

TRACE: (
0  CoreFoundation                      0x355e58a7 __exceptionPreprocess + 186
1  libobjc.A.dylib                     0x3798c259 objc_exception_throw + 32
2  CoreFoundation                      0x3553a1d7 -[__NSArrayM insertObject:atIndex:] + 186
3  MYAPP                               0x0006c0f7 MYAPP + 188663
4  MYAPP                               0x000652a3 MYAPP + 160419
5  Foundation                          0x3512ac29 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 16
6  Foundation                          0x350826d9 -[NSURLConnectionInternalConnection invokeForDelegate:] + 28
7  Foundation                          0x350826a3 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 198
8  Foundation                          0x350825c5 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 60
9  CFNetwork                           0x34de77f5 _ZN19URLConnectionClient23_clientDidFinishLoadingEPNS_26ClientConnectionEventQueueE + 192
10  CFNetwork                          0x34ddc4a5 _ZN19URLConnectionClient26ClientConnectionEventQueue33processAllEventsAndConsumePayloadEP20XConnectionEventInfoI12XClientEvent18XClientEventParamsEl + 424
11  CFNetwork                          0x34ddc1a3 _ZN19URLConnectionClient13processEventsEv + 106
12  CFNetwork                          0x34ddc0d9 _ZN17MultiplexerSource7performEv + 156
13  CoreFoundation                     0x355b9ad3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
14  CoreFoundation                     0x355b929f __CFRunLoopDoSources0 + 214
15  CoreFoundation                     0x355b8045 __CFRunLoopRun + 652
16  CoreFoundation                     0x3553b4a5 CFRunLoopRunSpecific + 300
17  CoreFoundation                     0x3553b36d CFRunLoopRunInMode + 104
18  GraphicsServices                   0x371d7439 GSEventRunModal + 136
19  UIKit                              0x33047cd5 UIApplicationMain + 1080
20  MYAPP                              0x0003fbcf MYAPP + 7119
21  MYAPP                              0x0003fb84 MYAPP + 7044
)

通过 CoreFoundation 等方法名称并询问用户发生了什么,我可以很好地了解崩溃发生的位置。

然而,自从 iOS 6 发布以来,我的崩溃报告都是这样的:

CRASH: NSRangeException (*** -[__NSArrayI objectAtIndex:]: index 2147483670 beyond bounds [0 .. 11])

TRACE: (
0  CoreFoundation                     0x3a3872bb <redacted> + 186
1  libobjc.A.dylib                    0x32ca697f objc_exception_throw + 30
2  CoreFoundation                     0x3a2d1e8d <redacted> + 164
3  MYAPP                              0x000ff721 MYAPP + 214817
4  MYAPP                              0x000e8999 MYAPP + 121241
5  UIKit                              0x372f60ad <redacted> + 72
6  UIKit                              0x372f605f <redacted> + 30
7  UIKit                              0x372f603d <redacted> + 44
8  UIKit                              0x372f58f3 <redacted> + 502
9  UIKit                              0x372e1287 <redacted> + 526
10  UIKit                             0x37373f3d <redacted> + 748
11  UIKit                             0x3721e52b <redacted> + 318
12  UIKit                             0x3720b809 <redacted> + 380
13  UIKit                             0x3720b123 <redacted> + 6154
14  GraphicsServices                  0x362085a3 <redacted> + 590
15  GraphicsServices                  0x362081d3 <redacted> + 34
16  CoreFoundation                    0x3a35c173 <redacted> + 34
17  CoreFoundation                    0x3a35c117 <redacted> + 138
18  CoreFoundation                    0x3a35af99 <redacted> + 1384
19  CoreFoundation                    0x3a2cdebd CFRunLoopRunSpecific + 356
20  CoreFoundation                    0x3a2cdd49 CFRunLoopRunInMode + 104
21  GraphicsServices                  0x362072eb GSEventRunModal + 74
22  UIKit                             0x3725f301 UIApplicationMain + 1120
23  MYAPP                             0x000ccbd3 MYAPP + 7123
24  MYAPP                             0x000ccb88 MYAPP + 7048
)

我从这里获取堆栈跟踪,当应用重新打开时,系统会提示用户发送电子邮件:

void uncaughtExceptionHandler(NSException *exception) {
    //make a file name to write the data to using the documents directory:
    NSString *fileName = [NSString stringWithFormat:@"%@/crashlog.txt", documentsDirectory];
    //create content - four lines of text
    NSString *content = [NSString stringWithFormat:@"CRASH: %@ (%@)\n\nTRACE: %@", [exception name], [exception reason], [exception callStackSymbols]];
    //save content to the documents directory
    [content writeToFile:fileName atomically:NO encoding:NSStringEncodingConversionAllowLossy error:nil];
}

没有方法名,这比没用还糟糕。有没有办法让这些方法名称回到我的堆栈跟踪中?这是发布配置,不是调试。

编辑:

我已按照this answer 中的说明进行操作。

我正在从.xcarchive 包中提取.app.dSYM 文件并运行atos -arch armv7 -o 'MyApp.app'/'MyApp'

但是,我仍然没有从 atos 获取方法名称。

【问题讨论】:

  • 跟进 - 我从来没有让这个工作,所以我放弃了崩溃报告的电子邮件,我现在使用 QuincyKit - 一个更好的解决方案。

标签: ios6 stack-trace


【解决方案1】:

您是否偶然安装了任何 iOS 6 测试版?我遇到了同样的问题。

这个question 帮助了我。

【讨论】:

  • 感谢您的回答,但这是一个略有不同的问题。崩溃日志在用户的设备上进行符号化,而不是在我的开发 Mac 上。我可以在我的 Mac 上表示来自用户设备而不是 iTunes 连接的崩溃日志吗?
  • 只要您拥有来自用户设备的构建的 dSym,您就可以进行符号化。自从 Xcode 成为一个合适的应用程序后,这个过程可能已经发生了变化,但可能有关于如何通过 Google 进行操作的教程。
【解决方案2】:

OP 在他的 EDIT 中提到了要使用的错误文件。

这篇文章包含了完成这项工作所需的所有信息:

Using atos to determine crashed method name with dSYM

明确说明在哪里可以找到使用 atos 运行的正确文件:

Atos cannot get symbols from dSYM of archived application

确保使用正确的架构;我尝试使用 armv7,但我需要指定 arm64

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-04-01
    • 2011-01-03
    • 2017-01-12
    • 2011-12-13
    • 2015-10-01
    • 1970-01-01
    • 2019-06-17
    相关资源
    最近更新 更多