EXC_BAD_ACCESS和Address Sanitizer下一步是什么？

Question

有一个应用，该应用是带有Messages扩展应用的iOS应用。他们共享大量的代码，这些代码与计算和编辑某些特殊对象的尺寸有关，然后使用它们来创建绘制路径。

该应用运行良好。消息应用程序的一个版本似乎在共享的代码中因EXC_BAD_ACCESS code=2而崩溃。调试时没有运气，因为崩溃的位置似乎随着我添加日志语句和重构代码而反弹。

因此，我专注于主应用程序。最初的尝试是打开Address Sanitizer，这导致了下面讨论的崩溃。然后，我编辑了该方案以查找“僵尸”，但没有发现任何东西，包括在“仪器”中。通过仪器没有内存泄漏或其他明显的分配错误。我编辑了方案以打开Malloc Scribble，Malloc Guard Edges和Guard Malloc，并且该应用程序运行良好，没有崩溃或控制台日志消息。

然后返回到Address Sanitizer，这是导致主应用程序崩溃的唯一选项，并且它与Messages应用程序位于同一区域。我认为如果我解决了一个问题，那么我可能会解决两个问题，并且该应用程序可能更容易调试，而无需成为扩展程序。

我搜索和阅读的每个链接似乎都说这些Xcode诊断程序将（或应该）识别出令人反感的代码，并且在编写Swift的几年中，这就是典型的情况。这个让我难过。

主视图控制器是UICollectionViewController，崩溃发生在最初的collectionView(:cellForItemAt)调用中。其他具有正常（准确）计数和大小的委托调用afaik并没有什么异常。 （同样，这仅与Address Sanitizer一起使用。）在获得可重用的单元格之后，我用一些默认值调用了getObjectEffects（该应用程序比较复杂，但是在这种超简单的硬编码值情况下也崩溃了）同样，因此我将调试保持尽可能简单），并为该函数的func定义标识了EXC_BAD_ACCESS。

这就是让我难过的原因。它不是在标识有分配或分配的代码，而是一个func语句。参数为Int和Bool。控制台的输出为零，我在其中也尝试了(lldb) command script import lldb.macosx.heap和(lldb) malloc_info —type 0x...，但没有结果。如前所述，我尝试了Zombies和其他Xcode内存管理诊断程序，却不了解为什么地址清理器在使用EXC_BAD_ACCESS的函数语句时崩溃，并且我不确定如何进一步诊断。

我错过了什么？感谢您的见解。

编辑：最终通过切换代码并寻找不同的结果而取得了进展。最终的“解决方案”是不合逻辑的，因为我无法弄清楚它在逻辑上应如何产生任何不同的结果，但是确实如此。并且由于它没有提供关于如何诊断EXC_BAD_ACCESS的原因的原始问题的知识，因此在此不再赘述。现在，这将是一个“已解决”的谜。