当将应用程序部署到设备时,程序将在几个周期后退出,并出现以下错误:

Program received signal: "EXC_BAD_ACCESS".

程序在iPhone模拟器上运行没有任何问题,只要我一次执行一个指令,它也会调试和运行。一旦我让它再次运行,我将击中EXC_BAD_ACCESS信号。

在这种特殊情况下,它恰好是加速度计代码中的一个错误。它不会在模拟器中执行,这就是它不会抛出任何错误的原因。但是,它将在部署到设备后执行。

这个问题的大多数答案都处理一般的EXC_BAD_ACCESS错误,因此我将保留这个选项,作为可怕的坏访问错误的统称。

EXC_BAD_ACCESS通常是非法内存访问的结果。你可以在下面的答案中找到更多信息。

您以前遇到过EXC_BAD_ACCESS信号吗?您是如何处理它的?


当前回答

再补充一下

Lynda.com有一个很棒的DVD叫

iPhone SDK基本培训

第6章第3课是关于EXEC_BAD_ACCESS和使用僵尸的。

这对我来说是很好的理解,不仅是错误代码,而且我如何使用僵尸来获得更多关于释放对象的信息。

其他回答

EXC_BAD_ACCESS信号是向系统调用传递无效指针的结果。我今天早些时候在OS X上用一个测试程序得到了一个-我传递了一个未初始化的变量到pthread_join(),这是由于早期的拼写错误。

我不太熟悉iPhone开发,但是你应该仔细检查你传递给系统调用的所有缓冲指针。一直提高编译器的警告级别(使用gcc时,使用-Wall和-Wextra选项)。在模拟器/调试器上启用尽可能多的诊断。

在EXC_BAD_ACCESS异常发生之前捕捉异常的另一种方法是XCode 4+中的静态分析器。

使用Product > Analyze (shift+cmd+B)运行静态分析器。 单击分析器生成的任何消息将在您的源上覆盖一个图表,该图表显示了保留/释放违规对象的顺序。

在我的例子中,我有一个视图(a),其中我有另一个视图(B)的实例。我忘记了B是a的子类,显然这导致了递归和无休止的分配。修复了EXE_BAD_ACCESS问题。

   class A: UIView {
 
      let b = B()
      .
      .
   }



   class B: A {
     .
     .
   }

调用NSAssert()来验证方法参数对于跟踪和避免传递nil也非常方便。

在12 Pro Max上尝试分配140000xScreen高度的ScrollView空间时EXC_BAD_ACCESS错误。它的分配很好,直到达到140,000像素的宽度。;)