设备上的EXC_BAD_ACCESS，但在模拟器上很好

Question

我有一个在模拟器上运行良好的滚动视图应用程序，但是，当我在设备上安装时，它会给我一个EXC_BAD_ACCESS，当我尝试滚动一页时。我已通过有分配和泄漏的仪器运行它，但没有任何泄漏，没有僵尸被消息...我只是好奇什么可能导致模拟器与设备之间的这种差异？任何调试方法，因为我的符号化崩溃日志（部分在下面），似乎没有象征性。

异常类型：EXC_BAD_ACCESS（SIGBUS）
例外代码：KERN_PROTECTION_FAILURE位于0x0000000f
崩溃的线程：0

线程0崩溃：
0 libobjc.A.dylib 0x0000286e objc_msgSend + 18
1 MyApp 0x00004fee 0x1000 + 16366
2 UIKit 0x000668f4 - [UIViewController视图] + 104
3 MyApp 0x00009716 0x1000 + 34582
4 MyApp 0x0000960c 0x1000 + 34316
5 UIKit 0x0001426c - [UIScrollView setContentOffset：] + 344

由于

Answer 1

你在模拟器中的代码可能有错误，但是没有触发EXC_BAD_ACCESS只是运气，你取消引用的指针不在未映射的内存中。一个指针可能是坏的，并且被访问但未被检测到 - 它仍然是一个错误。

你已经检查过没有收到过僵尸的消息，这本来是我的第一个建议。

接下来要做的是启用Guard Malloc - 然后阅读此

http://developer.apple.com/iphone/library/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html

您只能在模拟器中执行此操作 - 您的目标是使用额外敏感的堆来使错误在模拟器中抛出EXC_BAD_ACCESS。

在文章中：

1. 了解如何在GDB中设置变量
2. 阅读“检测堆腐败”部分

Answer 2

设备上的错误访问可能由于很多原因而导致，其中大多数都与设备内存少于模拟器的事实有关，因此它会更快地解除释放内存。

找到问题的最佳方法是在没有断点的调试模式下在设备上运行应用程序（为什么要这样做是添加断点然后删除它）。如果你可以通过这种方式重现糟糕的访问，在重现它之后，你可以看一下调试器控制台（cmd + shift + y），你会发现程序已经停在断点相同的地方，然后进入线程堆栈看到你的应用程序执行的最后一次调用失败，可能是访问错误的指针。

Answer 3

我想将我的案例添加到讨论中。我刚刚解决了一个与此问题非常相似的问题。它在模拟器上工作但在设备上失败了。认为这是一个记忆问题。事实并非如此。

原来我忘记了非{void}方法的return。预计会返回一个值，但我忘了完全返回。如果你问我这是非常糟糕的错误，但它在模拟器中运行没有问题（即使返回实际上用于存储变量并用它做一些其他的东西）。

不知何故，模拟器每次都忘记了返回。打败我怎么样，但我只能疯狂地猜测它必须将我使用的最后一个变量放在返回应该指向的同一个地方，从而导致错误（错误但正确）的返回。

然后在设备上运行，在正常情况下，它每次都会崩溃。我一步一步地调试，意识到我没有正确地返回失败方法的结果。

希望它可以帮助任何人面对这个问题！