xcode 如何在符号化崩溃报告（iPhone / Mac）中获得正确的行号？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1287074/
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
How to get correct line numbers in symbolicated crash reports (iPhone / Mac)?
提问by Martijn Thé
When symbolicating crash reports, I noticed that line numbers are off. I tested this with a project in which I deliberately cause a crash. It seems the generated line number do not include certain lines, e.g. comment lines or compiler preprocessor statements (not sure what it does and does not include)...
在符号化崩溃报告时，我注意到行号已关闭。我在一个故意导致崩溃的项目中对此进行了测试。似乎生成的行号不包括某些行，例如注释行或编译器预处理器语句（不确定它做什么和不包括什么）......
Is there an easy way to get from the "off" line number in the symbolicated crash report to the actual line of code in the source?
有没有一种简单的方法可以从符号化崩溃报告中的“关闭”行号到源代码中的实际代码行？
Edit: An example of a line in a symbolicated crash report:
编辑：符号化崩溃报告中的一行示例：
7 Luisterpaal 0x00005de2 -[SWFMP3 connection:didReceiveData:] (SWFMP3.m:320)
So, the line number 320 is almost correct, but not exactly. It's a few lines off...
因此，行号 320 几乎是正确的，但不完全正确。差几行了...
回答by iKenndac
In a word… no. If you're looking at a line like this in a crash report:
总之……不。如果您在崩溃报告中看到这样的一行：
0 com.apple.CoreFoundation 0x95cb046b CFArrayAppendValue + 43
0 com.apple.CoreFoundation 0x95cb046b CFArrayAppendValue + 43
The "+43" isn't a line number, but a memory location from the beginning of the function. The code as you wrote it simply doesn't exist in the compiled binary - the compiler optimises and changes the code (in a Release build, at least) around so it most often doesn't match what you wrote.
“+43”不是行号，而是函数开头的内存位置。您编写的代码在编译后的二进制文件中根本不存在 - 编译器优化和更改代码（至少在发布版本中），因此它通常与您编写的内容不匹配。
Unfortunately, the solution is to provide the person experiencing the crash with a debug version that you can remote debug or at least throw out NSLog() statements to help track it down, and/or write smaller methods.
不幸的是，解决方案是为遇到崩溃的人提供一个调试版本，您可以远程调试或至少抛出 NSLog() 语句来帮助跟踪它，和/或编写更小的方法。
回答by Brett Donald
I had this problem too, but only because I was looking at a newer version of code than what was compiled into the binary which crashed. When I went back in my source history and found the corresponding version of the source, the line numbers matched exactly.
我也遇到了这个问题，但这只是因为我正在查看比编译到崩溃的二进制文件中的代码版本更新的代码。当我返回源历史记录并找到源的相应版本时，行号完全匹配。
