CRT detected that the application wrote to memory after end of heap buffer

原创已于 2022-11-16 17:16:38 修改 · 1.7k 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#java #jvm #开发语言

于 2022-11-05 11:22:21 首次发布

VC++ 专栏收录该内容

13 篇文章

订阅专栏

本文详细解析了VS工程中出现的堆内存被破坏错误，包括错误的原因、常见的内存越界访问现象及如何定位此类问题。特别是针对静态库与主工程间因头文件不同步引发的内存异常进行了深入分析。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

   VS工程运行时出现这个错误：
   ![错误截图](https://img-blog.csdnimg.cn/1e5931c4bab8476cab6747bdfee0e9f8.png#pic_center)
   ![在这里插入图片描述](https://img-blog.csdnimg.cn/d9674c6f69e5483b85ee0304be11a412.png#pic_center)


   根据提示信息，检测到了堆内存被破坏，程序向堆内存前面的内存区域写入了内容。系统在分配堆内存时，会在给用户使用的堆内存前后加上头信息和尾信息，用来维护和管理这些堆内存，这些堆内存的头部内存和尾部内存区域，应用程序是不能写入的，是系统来维护和管理的。
   一般而言，造成这个问题的现象无外乎两种情况：
   （1）内存越界访问，比如数组越界访问；
   （2）指针释放后，没有赋值为null，第二次重复释放。
  总之是访问了不该访问的内存（不属于应用程序的内存）。
  仔细检查了代码，没有发现如上两种情况，好像我的不属于这两种情况，我的现象如下：
  只要类成员增加了新的变量，在释放的时候就报这个错误。
  经分析发现，这个类位于主程序使用的一个静态库中，主工程使用该类的时候，把头文件从静态库工程目录下复制到主工程目录下；静态库中在该类中增加了新成员后，忘记了在主工程更新该头文件，这样静态库中的该类占用空间大小和主工程中的大小不一致，那么在释放时就会造成堆越界异常（主工程分配该类对象的size比静态库中的小，释放时又调用静态库中的析构函数）。
  
  还有一种造成堆越界访问的现象，这种情况比较少见，但非常不易被发现，如下所示：
  char array[5]=new char[5];
  int count = 2;
  ...
  array[count]='d';//1.此时count 的值为-1，导致越界到数组前面了
  ...
  delete []array;//2.在此处发生异常
  即异常的地方并不是真正代码错误的地方。（一般数组前面记录着数组个数，释放的时候根据数组个数释放申请的内存，修改了数组前面的内存其实修改了数组的个数）。