当将应用程序部署到设备时，程序将在几个周期后退出，并出现以下错误:
Program received signal: "EXC_BAD_ACCESS".
程序在iPhone模拟器上运行没有任何问题，只要我一次执行一个指令，它也会调试和运行。一旦我让它再次运行，我将击中EXC_BAD_ACCESS信号。
在这种特殊情况下，它恰好是加速度计代码中的一个错误。它不会在模拟器中执行，这就是它不会抛出任何错误的原因。但是，它将在部署到设备后执行。
这个问题的大多数答案都处理一般的EXC_BAD_ACCESS错误，因此我将保留这个选项，作为可怕的坏访问错误的统称。
EXC_BAD_ACCESS通常是非法内存访问的结果。你可以在下面的答案中找到更多信息。
您以前遇到过EXC_BAD_ACCESS信号吗?您是如何处理它的?
当前回答
我只是在试图执行一个包含大数组的C方法时，才在iPhone上遇到了EXC_BAD_ACCESS。模拟器可以给我足够的内存来运行代码，但设备却不行(数组有一百万个字符，所以有点多了!)
EXC_BAD_ACCESS恰好出现在方法的入口点之后，让我困惑了好一阵子，因为它不在数组声明附近。
也许其他人能从我这几个小时的拔头发中获益。
其他回答
使用简单的规则“如果你没有分配或保留它，就不要释放它”。
调用NSAssert()来验证方法参数对于跟踪和避免传递nil也非常方便。
EXC_BAD_ACCESS信号是向系统调用传递无效指针的结果。我今天早些时候在OS X上用一个测试程序得到了一个-我传递了一个未初始化的变量到pthread_join()，这是由于早期的拼写错误。
我不太熟悉iPhone开发，但是你应该仔细检查你传递给系统调用的所有缓冲指针。一直提高编译器的警告级别(使用gcc时，使用-Wall和-Wextra选项)。在模拟器/调试器上启用尽可能多的诊断。
EXC_BAD_ACCESS的主要原因是试图访问已释放的对象。
要了解如何排除此故障，请阅读本文档: DebuggingAutoReleasePool
即使你不认为你在“释放自动释放的对象”，这也适用于你。
这个方法非常有效。我一直在用它，而且非常成功!!
总之，这解释了如何使用Cocoa的NSZombie调试类和命令行“malloc_history”工具来查找在代码中被访问的释放对象。
Sidenote:
运行仪器和检查泄漏将无助于排除EXC_BAD_ACCESS故障。我非常确定内存泄漏与EXC_BAD_ACCESS无关。泄漏的定义是您不再具有访问权限，因此不能调用它的对象。
更新: 我现在使用Instruments来调试泄漏。在Xcode 4.2中，选择Product->Profile，当Instruments启动时，选择“Zombies”。
如果您正在使用自定义字体，并且以编程方式实例化它们，则如果您之前没有在运行时注册字体，则会发生此错误。
为了确保是这样，Xcode控制台将打印如下内容:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1d8)
frame #0: 0x0000000180f969cc CoreText`CTFontGetClientObject + 12
...
or
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x000000012341c10e CoreFoundation`CFRelease.cold.1 + 14
frame #1: 0x00000001232ed7bd CoreFoundation`CFRelease + 77
frame #2: 0x0000000128136990 libGSFont.dylib`GSFontGetExtraData + 112
frame #3: 0x0000000135bc8958 UIFoundation`-[UIFont lineHeight] + 9
frame #4: 0x00000001340149f3 UIKitCore`-[UILabel intrinsicContentSize] + 331
...
要注册自定义字体并解决该问题，可以签出此解决方案:https://stackoverflow.com/a/69756114/3701102
