Question

我已经为以下问题提交了雷达（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;
}

Answer 1

编译器错误。谢谢你提交。

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

回应stackmaster;这是一个编译器错误。 ARC的重点是将Objective-C转换到编译器可以100％确定地分析代码的位置，以便了解保留/发布的位置，这样您，开发人员就不必这样做。总的来说，即使面对线程，它也可以实现这一点，只要在MRR世界中使用对象的所有代码都表现良好并且开发人员不会将对象“逃离”ARC控制和做一些顽皮的事。两个很大的问题，但比MRR有了很大的改进。

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

虽然有些编译器是臭名昭着的，但是LLVM不是其中之一（我不会对GCC提出索赔，因为我多年没有使用过它，但我敢打赌也可以这么说）。 iOS或OS X系统将在每次启动时执行数百万行编译并启用优化代码，系统运行良好。

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

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

使用-Os在objc ARC下过度释放，但不使用-O0

1 个答案: