我已经提出了以下问题的雷达(rdar：// 12311693,http://openradar.appspot.com/12311693),但是我以为我会在这里发布,看看有没有人可以在我的代码中发现可能导致崩溃的错误.
以下代码示例导致在使用编译器优化(-Os)构建时由于过度释放导致崩溃,但在关闭编译器优化(-O0)时不会崩溃.该项目正在使用Xcode 4.4.1(4F1003),Apple LLVM编译器4.0
当num2被过度释放时,应用程序崩溃.启用僵尸对象以确认是这种情况.
// This crashes under -Os,but not under -O0
NSNumber *num1 = @((float)arc4random() / (float)UINT32_MAX);
NSNumber *num2 = @((float)arc4random() / (float)UINT32_MAX);
NSNumber *foo1 = num1;
NSNumber *foo2 = num2;
for (NSUInteger i=0; i<2; i++) {
NSLog(@"foo1: %p %@",foo1,foo1);
NSLog(@"foo2: %p %@",foo2,foo2);
// swap foo1 and foo2
foo1 = num2;
foo2 = num1;
}
解决方法
编译器错误.感谢您提交.
num1和num2应保证指向实例的使用寿命.我怀疑优化器是[正确]重复使用堆栈槽,并且[错误地]发出导致该问题的版本/保留序列.
响应栈主它是一个编译器错误. ARC的全部要素是将Objective-C转换为编译器可以100％确定性地分析代码,以了解保留/发布的位置,以便您,开发人员不必.总而言之,即使面对线程,即使在使用MRR世界中的对象的所有代码都表现良好,开发人员也不会将对象从ARC控制中“逃脱”做一些调皮两个大的ifs,但是对MRR的巨大改进.
最后,如果您的代码在优化时无效(当没有编译器错误发挥时),这是因为您的代码已损坏.正确编写的优化器不会打破正确的代码.
虽然一些编译器臭名昭着,但LLVM并不是其中的一个(我不会就GCC提出索赔,因为我几年没有使用,但是我敢打赌也可以这样说). iOS或OS X系统将在每次启动时执行数百万和数百万行的编译与优化启用代码,并且系统工作得很好.
所以,不,“优化器被打开”从来没有崩溃的最终解决方案.
正如Catfish_man所说,有一些深奥的优化器选项将有意义地产生技术上错误的代码.它们未被-O或其他“标准”优化启用.它们主要集中在数学运算上,因此通常不会导致崩溃,同样更快的错误蠕变到计算中.
