小编Jef*_*fro的帖子

iTunesConnect for my XCode 3.2.5构建的应用程序上的崩溃日志显示方法名称,但不显示行号.例如,在我在下面粘贴的简略崩溃报告中,它显示了这样:

0x000f5ef8 -[MyTableViewController dealloc] + 120

这里有两件令我困惑的事情,我会欣赏一些见解.第一个原因是来自iTunesConnect的原始.crash文件已经部分符号化:它显示了类和方法名称,但不显示源代码文件和行号.我希望生iTunesConnect到崩溃日志显示刚才的十六进制地址.据我了解,只有一次我将崩溃日志下载到我的本地系统并使用适当的工具(XCode Organizer,symbolicatecrash,atos,gdb x/i命令等)以及确切的应用程序二进制文件和dSYM文件显式绑定它(那些具有匹配的UUID),我会看到类,方法,源代码文件和行号的完整符号.即使我在Windows框中下载并查看崩溃日志,它也会显示为部分符号.我担心我的分发二进制文件必须包含一些调试符号,以便在原始崩溃日志中显示此信息,尽管在其分发目标设置中设置了"条带链接项目".这里的任何见解都会很棒.

令我感到困惑的第二件事,就是我在解决这一备受瞩目的事故中更为直接的关注​​,就是这种抵消的业务.我已经非常仔细地找到了带有匹配UUID的dSYM和应用程序二进制文件,将它们放在我的主目录中,以便Spotlight等人可以找到它们,无论我做什么,我都无法将该偏移量转换[MyTableViewController dealloc] + 120为源代码文件(我知道是MyTableViewController.m)和行号.我使用原始的iTunesConnect .crash文件尝试了以下技巧:

• XCode Organizer:它的"符号化"不会影响崩溃日志的变化 - 它是一样的.
• symbolicatecrash:在详细模式下它并没有真正抱怨什么,输出崩溃日志是一样的
• gdb:使用XCode 3.2.5用于生成分发版本的相同gdb和-arch设置,并按照此帖子在匹配的应用程序二进制和dSYM符号中加载,gdb'x/i'和'info line*'命令告诉我[MyTableViewController dealloc] + 120在完全不同的文件中对应于完全不相关的代码库 - 甚至是.h文件!野鹅追逐.

这有些不对劲.即使在崩溃报告,应用程序二进制文件和dSYM文件中确保完全相同的UUID,这些工具都不能产生实际的行号,并且以低级方式执行它会让我进行疯狂的追逐.知道确切的行号对于解决这个问题至关重要,因为我们无法在内部重现这次崩溃,因此我们在这里失明.这看起来是一个简单的过度释放的对象,但它不清楚它是哪个确切的对象,我们无法从上下文中分辨出来.我想知道是否有一些盗用的XCode构建设置在某种程度上打破了符号化过程.

谢谢你的时间!

以下是来自iTunesConnect的删节原始.crash日志.

Incident Identifier: 09EAE058-7D55-4AE5-947A-17280FB0211A
Hardware Model:      iPhone3,1
Process:         MyApp [1895]
Path:            /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
Identifier:      MyApp
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2011-01-24 14:06:32.941 -0500
OS Version:      iPhone OS 4.2.1 (8C148)
Report Version: …

我想在构建我们的发布iOS二进制文件时禁用在我们的代码行中发生的NSAssert调用,然后我想确认它们被禁用,因为我是超级偏执.我如何确认他们被禁用？

要在我们的发布版本中禁用NSAssert调用,我已将NS_BLOCK_ASSERTIONS = 1(从此处)常量添加到我正在使用xcodebuild进行的命令行发布构建,以便在整个应用程序的构建中阻止NSAsserts,包括构建所有我们使用的静态库.有几十个静态库,尝试验证每个lib的项目文件中都设置了这个标志是太多的维护,所以这种全局方法是首选.它看起来像这样:

xcodebuild -target MyApp -configuration MyReleaseConfig -DNS_BLOCK_ASSERTIONS=1 build

然后确认我们对NSAssert的调用确实被阻止了,这是我正在尝试的,我在寻求建议的地方:我从生成的二进制文件中转储符号表,并为NSAssert宏调用的实际方法进行grepping,像这样:

# Use 'nm' tool to dump symboltable into txt file
/Applications/Xcode.app/Contents/Developer/usr/bin/nm MyApp.app/MyApp > MyApp.symbols.txt

# Search symbols for NSAssertionHandler:
grep "NSAssertionHandler" ./MyApp.symbols.txt

# Output results:
RESULT=$?
if [ $RESULT -eq 0 ]
then
    echo -e "** ASSERTION CHECKER FAILED: FOUND 1 OR MORE NSASSERT CALLS IN RELEASE BINARY **"
else
    echo -e "** ASSERTION CHECKER SUCCEEDED:  NO NSASSERT CALLS IN RELEASE BINARY **"
fi

问题是我仍然看到NSAssertionHandler出现在符号中:

U …