那么你在objc_msgSend()方法里崩溃了。咋回事？
一般来说，你向一个已经释放的对象发送了消息。或者也许你的指针是完全正确的，但是别人破坏了这个对象的内容-可能是一个缓冲区超出了附近的申请空间，或者使用了一个悬挂指针这个指针指向的内存现在被你的对象占用。偶尔objc_msgSend()会因为内存错误破坏了runtime自有的数据结构而导致崩溃，但是通常是接收者自身对象导致。
无论你是否是在调试或者查找崩溃日志，你都可以发现更多崩溃信息不仅仅是向后追踪。
接收者和方法选择器寄存器
objc_msgSend()工作时存储接收者对象和方法选择器在CPU寄存器中。这些值会帮助判定问题。
寄存器的名字依赖于架构和objc_msgSend()的各种调用方式而不同。以下列表试用于Mac OS X美洲豹系统并且可能将继续试用于雪豹系统。
| objc_msgSend objc_msgSend_fpret | objc_msgSend_stret | |||
|---|---|---|---|---|
| receiver | SEL | receiver | SEL | |
| i386 | eax* | ecx | eax* | ecx |
| x86_64 | rdi | rsi | rsi | rdx |
| ppc | r3 | r4 | r4 | r5 |
| ppc64 | r3 | r4 | r4 | r5 |
| arm | r0 | r1 | r1 | r2 |
| arm64 | x0 | x1 | — | — |
上方列表没有做合并，请参考原文列表
i386说明：接收者在大多数崩溃中都是eax寄存器，但不全是。如果你在挂起前距离objc_msgSend()很远，此时eax寄存器可能会有其他值。
解释接收者和非法地址
你可以使用引发崩溃的接收者地址和非法地址来获取一些有关潜在问题的暗示。在一个崩溃日志中，接收者的地址处在线程状态中并且使用上边列表中寄存器的名字，并且非法地址被列在列表的顶部（通常使用一些像 KERN_PROTECTION_FAILURE at <invalid address>）。
在调试器控制台中，当程序停止时这个非法地址会被打印，并且你可以使用上方列表中的寄存器名字来打印接收者的地址。
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000001
0x00090ec4 in objc_msgSend ()
(gdb) p/x $eax
$1 = 0x1
我的测试程序崩溃在[(id)1 release]处。在真实的崩溃中，这些值将会更加典型而且有趣。
通常，两种情况可能会发生。接收者自身地址是假冒的，并且这个非法地址是相同的值（16或者32字节）。或者接收者地址是合理的，然后非法地址是接收者的isa指针。如果你试图使用一个已经释放的对象或者其他人clobbered你的合理对象，后一种情况通常会发生。
在你的崩溃中查看这些特殊值。也可以查看附近的一些值，在一些架构中，一个非法的isa指针将会导致在isa+16或者isa+32处崩溃。
没有以16字节分离 - 没有对准
malloc() 函数返回16-字节对齐的内存块。如果你的接收者不是16字节对齐，那它可能永远都不是一个合法的对象指针。
高两位和低两位都设置为 - 分配释放列表
一个内存块被释放后，内存分配器将会在这个内存块中写入释放列表指针。如果你在这之后用了一个已经释放的对象，你将会看到isa指针高两位和低两位都被设置了。
所有位被反转 - 垃圾回收列表
就像上配的分配释放列表的例子，但是是由于垃圾回收导致的崩溃。在这种情况下，address 看起来是坏的，但是~address 是更合理的。
0xa1b1c1d3 - CF容器
CoreFoundation容器使用这个值来删除或者清空元素。有可能一个被释放的对象已经被容器重新分配了内存，或者一些人使用了一个释放过的容器，这个容器已经被重新分配给你的对象使用，或者你从容器中读取指针，同时其他线程也在修改这个指针，你并没有在合适的地方加锁。
ASCII 文本
也许一个已经释放的对象被重新分配给了一个字符串，或者一些人使用了一个释放过的字符串而它已经被重新分配给你的对象，又或者一些字符串操作越界。使用 asciify 命令来快速打印这些字节序列。这看起来像是URL关联的，比如：
% asciify 0x2e777777
###.www###
###www.###
询问方法选择器
编译器优化意味着调用方指向的回溯中的第二帧并不是真实的崩溃调用。有可能是调用成功了，然后这个方法触发了一个尾调用导致崩溃。由于尾调用优化，这个独立帧将会在回溯中丢失。我们可以使用选择器寄存器来决定谁才是真正的崩溃调用。
一个方法选择器是一个指向独立的c字符串的指针。在将来的操作系统版本中这可能会发生改变，但是现在对于调试它是触手可及的。如果你已经在调试器中崩溃，打开调试控制台并且运行以下命令，替换为上方列表中正确的SEL 寄存器：
(gdb) x/s $ecx
0xa1029: "release"
雪豹系统的崩溃报告服务在崩溃日志中加了选择器的名字：
Application Specific Information:
objc_msgSend() selector name: release
除此之外，从崩溃日志中去除选择器的名字是困难的并且总是没有效果。当你有了雪豹系统，尝试以下方案，希望好运。
1.从崩溃日志的线程状态中，使用上方列表中的寄存器名字找到SEL的值。
ecx: 0x000a1029
2.从崩溃日志的二进制镜像中，找到地址范围在SEL的值内的镜像。该镜像通常要么是程序本身要么是libobjc.A.dylib。如果没有镜像跨越那些地址，请放弃。
0x8b000 - 0x106ff7 libobjc.A.dylib ??? (???) <9b5973b7fa88f9aab7885530c7b278dd> /usr/lib/libobjc.A.dylib
3.在崩溃日志中找到匹配镜像的拷贝。使用UUID来确认匹配。
% dwarfdump -u /usr/lib/libobjc.A.dylib
UUID: 26650299-C6EA-B1C8-52D6-072AC874D400 (ppc) /usr/lib/libobjc.A.dylib
UUID: 9B5973B7-FA88-F9AA-B788-5530C7B278DD (i386) /usr/lib/libobjc.A.dylib
UUID: D2A4E8E1-3C1C-E0D9-2249-125B6DD621F8 (x86_64) /usr/lib/libobjc.A.dylib
这次崩溃匹配我已经安装的 i386 libobjc.A.dylib库。如果这是系统库，你可能需要崩溃日志中列出的操作系统版本的镜像。如果它是应用程序，你需要保存拷贝每个版本的拷贝，是吧？
4.计算SEL在镜像中的偏移量
0xa1029 - 0x8b000 = 0x16029
5.打印镜像中在这个偏移量处的c字符串。记得指定正确的架构
% otool -v -arch i386 -s __TEXT __cstring /usr/lib/libobjc.A.dylib | grep 16029 00016029 release
（本文仅供参考，有任何翻译问题请指正，感谢原文作者）
