为何AddressSanitizer将野指针报为heap-buffer-overflow而非use-after-free？

1. 关于已释放内存被重新分配导致问题的可能性 #

没错，这种情况完全有可能是已释放的内存被其他代码重新分配引发的。当你释放某个View对象的内存后，这块内存空间会被归还给系统的内存分配器，后续其他代码申请内存时，分配器很可能把这块“闲置”的内存重新分配出去。如果此时你的代码里还有指向原View对象的悬空指针，并且不小心操作了它，就会出现两种典型问题：

• 要么修改了新分配到这块内存的对象数据，引发莫名其妙的逻辑错误；
• 要么读取的是新对象的内容，导致程序行为异常甚至崩溃。

2. View对象删除后立即调用NotifySettingsChanged触发use-after-free的原因 #

这个报错的原因很直接：NotifySettingsChanged内部大概率还在尝试访问已经被删除的View对象的成员变量或方法。当你刚删除View对象，它的内存虽然被标记为释放，但可能还没被覆盖或者重新分配，此时NotifySettingsChanged去操作这块内存，就触发了内存检测工具（比如ASAN）的use-after-free告警。

举个常见场景：假设View对象初始化时注册了一个设置变更的回调，删除View时没有把这个回调从通知队列中移除，调用NotifySettingsChanged时依然遍历到这个悬空指针，试图调用它的回调方法，自然就踩了已释放的内存。

建议的修复方向 #

• 提前清理通知关联：在删除View对象前，先把它从NotifySettingsChanged会访问的所有注册列表中移除，切断后续通知和它的关联；
• 改用智能指针管理内存：比如用std::unique_ptr或std::shared_ptr（根据场景选择），避免手动管理内存时出现悬空指针；
• 添加安全检查：在NotifySettingsChanged内部，对要访问的对象指针先做非空判断，同时确保指针指向的对象确实处于存活状态；
• 借助内存检测工具：比如ASAN、Valgrind，帮助你精准定位悬空指针的来源和触发点。

内容的提问来源于stack exchange，提问作者Joey.Z