iOS应用更新字典时崩溃：堆损坏及NSIndexPath未识别选择器求助

先给你拆解下当前的核心问题：你之前遇到的堆损坏（Heap corruption）和现在的-[NSIndexPath count]: unrecognized selector崩溃是连锁反应——0x8000000000000000这个地址是典型的无效对象地址，要么是这个NSIndexPath实例已经被释放（野指针），要么是内存被其他操作覆盖，把原本的集合类对象（比如数组/字典）“改成”了NSIndexPath，而后者正是堆损坏的直接表现。

下面是一步步的排查和解决方向：

1. 先定位崩溃的具体代码行 #

你的崩溃栈里有0x10952fbdc这类内存地址，直接在Xcode里就能解析：

• 打开Debug Navigator（左侧栏那个虫子图标），点击崩溃的线程，Xcode会自动跳转到对应的代码行；
• 如果没自动跳转，用终端的atos工具解析：运行atos -arch arm64 -o 你的App可执行文件路径 0x10952fbdc（把架构、可执行文件路径、崩溃地址换成你自己的），就能找到到底是哪一行代码在给NSIndexPath发count消息。

2. 排查为什么NSIndexPath会收到count消息 #

count是数组、字典这类集合类的方法，所以大概率是你的代码把NSIndexPath错误当成了集合类来用，常见场景：

• 你的图片字典里，某个key对应的value本该是UIImage/数组，但被错误存成了NSIndexPath；
• 在更新字典后刷新tableView时，某个逻辑把indexPath当成数据源数组来遍历（比如写代码时手滑，把dataArray[indexPath.row]写成了indexPath）；
• 内存被覆盖：堆损坏导致原本的集合类对象内存被NSIndexPath的内容覆盖，后续调用count就会触发崩溃。

3. 回到堆损坏的根源排查 #

堆损坏通常由以下场景导致，结合你加载图片的逻辑检查：

• 多线程冲突：如果你在后台线程加载图片并更新字典，同时主线程在读取字典，没有加锁或使用线程安全容器（比如NSMapTable或者GCD串行队列），容易引发内存写入混乱；
• 内存越界：加载图片时如果用了C语言的内存操作（比如malloc/free），有没有可能写入超过分配的内存大小？
• 过度释放：ARC下有没有用__unsafe_unretained修饰图片对象，导致对象被释放后还被访问？或者手动管理Core Graphics对象时没正确释放？

4. 用好你已经开启的调试工具 #

你开的几个工具都是排查内存问题的利器，重点看：

• Address Sanitizer：它会在内存错误发生时立刻中断，而不是等到后续崩溃。重新运行App，等它触发时，查看它给出的详细报告，里面会明确指出哪一行代码导致了内存越界、野指针等问题；
• Zombie Objects：如果是对象被过度释放，Zombie会告诉你这个对象原本的类型、被释放的位置、以及后续被访问的位置，帮你定位野指针的来源。

5. 检查tableView刷新与字典更新的线程安全 #

• 所有UI相关的数据源更新（包括你的图片字典）必须在主线程执行，后台线程更新字典后，一定要通过DispatchQueue.main.async来更新字典并刷新tableView；
• 刷新tableView时，确认代码逻辑正确，比如reloadRows(at: [indexPath], with: .automatic)里的indexPath是正确的，没有把其他对象当成indexPath传入。

举个可能的例子：假设你在后台加载图片时，不小心把indexPath当成图片对象存进了字典，之后在cellForRowAt里取字典值并调用count，就会触发这个崩溃。

内容的提问来源于stack exchange，提问作者Medwe