objective-c - 使用 dSYM 文件对故障转储进行符号化时,为什么 GDB 会显示 "no line number info available"?

标签 objective-c cocoa gdb crash-dumps debug-symbols

我构建了一个 Mac OS X 应用程序,该应用程序配置为剥离发布的调试信息并创建 dSYM 文件。

(项目配置如下所述:http://bit.ly/tJEQml http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html 的缓存版本,该版本已不再存在)

正如预期的那样,为我的应用程序生成的崩溃报告不会显示我的应用程序内部调用的堆栈跟踪的行信息。

在分析崩溃报告时,我无法让 GDBatos 为我提供堆栈跟踪的行信息。

崩溃报告摘录:

0   CoreFoundation          0x00007fff920f7286 __exceptionPreprocess + 198
1   libobjc.A.dylib         0x00007fff91f74d5e objc_exception_throw + 43
2   CoreFoundation          0x00007fff920f70ba +[NSException raise:format:arguments:] + 106
3   CoreFoundation          0x00007fff920f7044 +[NSException raise:format:] + 116
4   CoreFoundation          0x00007fff920b429b -[__NSCFDictionary setObject:forKey:] + 219
5   AppName                 0x00000001015e9c61 AppName + 85089

我通过执行以下操作尝试了GDB:

  1. 称为gdb -arch x86_64
  2. 使用 file 命令加载应用(尝试了 AppName.app 和 Content/MacOS/AppName)
  3. GDB 提示符号已加载(甚至尝试使用 file 加载 dSYM)
  4. 称为信息行 * 0x00000001015e9c61
  5. GDB 响应没有可用于地址 0x1015e9c61 的行号信息

我通过执行以下操作尝试使用atos:

  1. 称为atos -arch x86_64 -o AppName.app(也尝试直接访问二进制文件和dSYM的DWARF文件)
  2. 输入 0x00000001015e9c61 并按 Enter
  3. atos 只是重复 0x00000001015e9c61

可能出了什么问题?

这些符号似乎加载正确(至少 gdb 报告的是这样的),并且我确信崩溃、dSYM 和应用程序包都匹配。

最佳答案

我仍然没有弄清楚如何使手动符号化工作,但我找到了一个很好的脚本,可以自动完成它。

该脚本位于:https://github.com/nikyoudale/symbolicatecrash-mac

我将通读脚本的代码以弄清楚它在做什么并回答我自己的问题。

关于objective-c - 使用 dSYM 文件对故障转储进行符号化时,为什么 GDB 会显示 "no line number info available"?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8407043/

相关文章:

ios - 如何以编程方式在 iOS 中将 .png 图像转换为 .pdf

GDB 跟踪 : No current trace frame

c++ - 如何在裸机上运行 gcov(没有文件系统)

objective-c - 如何通过 mac os x api 获取 Safari.app 的包标识符

iphone - 从 NSRegularExpression 匹配中获取 NSRange

cocoa - NSTextField 带阴影?

ios - 我应该指定任何路径来访问 Xcode 中的头文件吗?

c++ - 为什么 gdb 显示两种不同的返回?

ios - Ios方法重载和方法重写有什么区别

objective-c - 在外部应用程序 Objective-C 中获取当前文件