What could cause DAMAGE: after normal block error?

What could cause DAMAGE: after normal block error?

悸初 发布于 2021-11-29 字数 222 浏览 747 回复 3 原文

I keep getting this error after my application is running for 2 days.

I've been told it's been some kind of buffer overflow, but is it the only option?

The app is written in C++ using Visual C++ 6.0.

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。



需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。


萌吟 2022-06-07 3 楼

With the correct options, Visual C++ throws a guard value at the end of each buffer. When you free the buffer, it checks that this is still valid. If not, it raises the error that you're seeing.

The most common cause of this error is a buffer overrun. However, it can (theoretically) be caused by a random pointer write (after all, it could write to the guard value).

Odds are, though, it's an overrun.

可是我不能没有你 2022-06-07 2 楼

The simplest way to reproduce this is something like this:

//Allocate space for holding 10 ints
int *p = new int[10];

//Overwrite the memory.. doesn't crash here
p[10] = 8;

//Try to delete..crashes..
delete[] p;

Check whether you are writing to the memory location beyond its allocated space.

风情万种。 2022-06-07 1 楼

In debug, when you get dynamic buffer by new, a special code gets inserted before and after the buffer to guard the buffer.


<Guard>=====buffer allocated on heap of required size=======<Guard>

If you overrun the buffer, the guard inserted gets corrupted and when you try to delete the buffer, then debugger would assert after detecting buffer overrun.

Its bit difficult to find the buffer overrun in large code base. I would suggest couple of ways which can help you to detect this scenario:

  • Using tools like Rational Purify:
    Its good tool to detect memory corruption.
  • Debugging by Windbg with GFlags
    Refer my answer to similar question here