Debug模式下C++触发__debugbreak断点与堆损坏报错排查

这是非常典型的堆内存越界写入故障，和你贴出来的new[]/delete[]配对语法本身没有关系，问题出在你省略的// Do something代码逻辑里。

• 你看到的__debugbreak()提示不是你手动加的断点，是Windows调试堆的主动检测逻辑触发的：Debug模式下CRT会在每个动态申请的内存块首尾插入特殊的保护字节（guard bytes），申请、释放内存的时候都会校验这些字节的完整性，一旦发现被篡改就会立刻触发断点，抛出堆损坏错误。Release模式默认关闭这些开销极高的调试检测，越界写入的破坏不会立刻暴露，只是没当场崩溃而已，问题本身一直存在，运行久了会随机出现崩溃、数据错乱，不是真的运行正常。
• 故障不在第一次循环触发完全符合堆损坏的特征：如果前几次越界写入的位置刚好没踩到堆的关键元数据或者保护字节，检测逻辑不会触发，等多次写入累积的破坏碰到检测点的时候才会报错，没有固定的触发时机。

1. 先逐行检查所有操作renderableShapeIndices数组的代码，90%的同类问题都是数组下标越界：最常见的就是遍历数组时循环条件写错，比如把终止条件写成i <= aNumberCreatedAtRuntime，最后一次循环刚好写到数组尾部的保护字节上，等执行delete[]触发堆校验的时候就会报错。
2. 检查有没有对这个指针做错误操作：比如中途给指针重新赋了别的值，导致delete[]释放的不是new返回的原始地址；或者有没有野指针在数组释放之后，还往这块已经回收的内存地址写数据。
3. 最快的定位方式是在VS里开启地址消毒器（Address Sanitizer），Debug模式下编译运行，越界写入发生的瞬间就会直接断在出错的代码行，不需要逐行猜逻辑。

别觉得new[]和delete[]配对写了就不会出内存问题，这种只在Debug模式下报的堆损坏，几乎都是数组操作越界踩内存导致的，和内存释放的语法配对无关。

内容的提问来源于stack exchange，提问作者Christopher Barrios Agosto