当将应用程序部署到设备时，程序将在几个周期后退出，并出现以下错误:
Program received signal: "EXC_BAD_ACCESS".
程序在iPhone模拟器上运行没有任何问题，只要我一次执行一个指令，它也会调试和运行。一旦我让它再次运行，我将击中EXC_BAD_ACCESS信号。
在这种特殊情况下，它恰好是加速度计代码中的一个错误。它不会在模拟器中执行，这就是它不会抛出任何错误的原因。但是，它将在部署到设备后执行。
这个问题的大多数答案都处理一般的EXC_BAD_ACCESS错误，因此我将保留这个选项，作为可怕的坏访问错误的统称。
EXC_BAD_ACCESS通常是非法内存访问的结果。你可以在下面的答案中找到更多信息。
您以前遇到过EXC_BAD_ACCESS信号吗?您是如何处理它的?
当前回答
甚至还有另一种可能:在队列中使用块，很容易发生你试图访问另一个队列中的对象，这个对象此时已经被取消分配了。通常当你试图向GUI发送一些东西时。 如果异常断点设置在一个陌生的位置，那么这可能是原因所在。
其他回答
在你做任何事情之前，你应该尝试:
产品->清洁
然后再跑。这对我很管用。否则，我会浪费好几个小时。
EXC_BAD_ACCESS的主要原因是试图访问已释放的对象。
要了解如何排除此故障，请阅读本文档: DebuggingAutoReleasePool
即使你不认为你在“释放自动释放的对象”，这也适用于你。
这个方法非常有效。我一直在用它，而且非常成功!!
总之，这解释了如何使用Cocoa的NSZombie调试类和命令行“malloc_history”工具来查找在代码中被访问的释放对象。
Sidenote:
运行仪器和检查泄漏将无助于排除EXC_BAD_ACCESS故障。我非常确定内存泄漏与EXC_BAD_ACCESS无关。泄漏的定义是您不再具有访问权限，因此不能调用它的对象。
更新: 我现在使用Instruments来调试泄漏。在Xcode 4.2中，选择Product->Profile，当Instruments启动时，选择“Zombies”。
根据我的经验，这通常是由非法内存访问引起的。检查所有指针，特别是对象指针，以确保它们已初始化。确保你的主窗口。Xib文件(如果您正在使用的话)已正确设置，并具有所有必要的连接。
If none of that on-paper checking turns anything up, and it doesn't happen when single-stepping, try to locate the error with NSLog() statements: sprinkle your code with them, moving them around until you isolate the line that's causing the error. Then set a breakpoint on that line and run your program. When you hit the breakpoint, examine all the variables, and the objects in them, to see if anything doesn't look like you expect.I'd especially keep an eye out for variables whose object class is something you didn't expect. If a variable is supposed to contain a UIWindow but it has an NSNotification in it instead, the same underlying code error could be manifesting itself in a different way when the debugger isn't in operation.
在创建字符串时不要忘记@符号，将c -string作为nsstring将导致EXC_BAD_ACCESS。
用这个:
@"Some String"
而不是这样:
"Some String"
PS——通常是在填充包含大量记录的数组内容时。
运行应用程序，在它失败后(应该显示“中断”而不是“EXC_BAD_ACCESS”…检查控制台(Run > Console)…现在应该有一条消息告诉它要访问什么对象。
