10

我已经为以下问题提交了一个雷达（rdar://12311693，http ://openradar.appspot.com/12311693 ），但我想我也会在这里发布，看看是否有人能发现错误我的代码可能导致崩溃。

以下代码示例在打开编译器优化 (-Os) 时由于过度释放而导致崩溃，但在关闭编译器优化 (-O0) 时不会崩溃。该项目正在使用 Xcode 4.4.1 (4F1003)、Apple LLVM 编译器 4.0 构建

当 num2 过度释放时，应用程序崩溃。启用 Zombie Objects 以确认是这种情况。

// 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;
}
4

1 回答 1

6

编译器错误。感谢您提交它。

num1并且num2应该保证指向实例的生命周期。我怀疑优化器 [正确] 重用堆栈槽并 [不正确] 发出导致问题的释放/保留序列。

回应堆栈管理员；这是一个编译器错误。ARC 的全部意义在于将 Objective-C 转换到编译器可以 100% 确定地分析代码以知道在哪里粘贴保留/释放的点，这样开发人员就不必这样做了。总的来说，它完全可以做到这一点，即使面对线程，只要在 MRR 世界中使用对象的所有代码都表现良好并且开发人员不会“逃脱”对象超出 ARC 控制和做一些淘气的事。两个大如果，但对 MRR 有很大的改进。

最后，如果您的代码在优化时不起作用（当没有编译器错误起作用时），那是因为您的代码损坏了。正确编写的优化器不会破坏正确编写的代码。

虽然有些编译器出了名的漏洞百出，但 LLVM 并不是其中之一（我不会对 GCC 发表任何声明，因为我已经很多年没有使用过它了，但我敢打赌也可以这么说）。iOS 或 OS X 系统将在每次启动时执行数百万行已启用优化的编译代码，并且系统运行良好。

所以，不，“优化器已打开”永远不是崩溃的最终解决方案。

正如 Catfish_man 所指出的，有一些深奥的优化器选项会故意产生技术上不正确的代码。它们不是由 -Os 或其他“标准”优化启用的。它们主要集中在数学运算上，因此通常不会像更快地计算错误那样导致崩溃。

于 2012-09-17T17:20:24.140 回答