求助.....内存管理 new/delete ....

[klmswt]

我在c++程序中多次利用new来申请空间，为了防止内存泄漏，在结束时用delete来释放指针变量。
但是程序在执行到delete时出现debug错误： DAMAGE: after Normal Block(#x),不知原因何在？
如果不用delete 释放的话，程序执行几次之后将无法执行，估计是内存泄漏。

程序基本代码如下：
static void f1(int n)
{
unsigned short *p1, *p2;
p1 = new unsigned short[n];
memset(p1, 0 ,n*sizeof(unsigned short));
p2 = new unsigned short[n];
memset(p2, 0 ,n*sizeof(unsigned short));
...
...
f2(p1,p2,n);
...
..
delete []p2;
delete []p1;
}

static void f2(unsigned short *a, unsigned short *b, int n)
{

unsigned short *x, *y, *z;
x = new unsigned short[n/2];
memset(z, 0 ,n/2*sizeof(unsigned short));
y = new unsigned short[n/2];
memset(y, 0 ,n*sizeof(unsigned short));
z = new unsigned short[n/2];
memset(z, 0 ,n/2*sizeof(unsigned short));
...
...
delete []z;
delete []y;
delete []x;
}

[arfi]

这些代码看上去没问题。

[qingwuzhu]

不要用DELETE　语句啊

[liu_feng_fly]

unsigned short *x, *y, *z;
x = new unsigned short[n/2];
memset(z, 0 ,n/2*sizeof(unsigned short));？？？
~~~~应该是x吧

[cxjxue]

NO Problem

[klmswt]

不好意思敲错了，程序中是x.
我的程序中还有比较复杂的操作，这些只是一个结构，为了表述问题。

大家有没有遇到过这种问题，什么情况可能造成这种错误。

[qingwuzhu]

在函数内基本数据类型可以不用删除语句，而不会发生内存

[klmswt]

to qingwuzhu(回眸一笑) :
但是如果不用的话，我的程序多次执行后就出现异常。
但是如果重新启动执行环境，就又可以了，这是不是因为内存空间恢复了。

[klmswt]

问题已经找到了，是因为越界了，因为将边界标志覆盖了，所以在删除时就出现错误了。

[xiaoyunet]

你在函数f2中有没有释放指针a,b？如果是这样。就会出问题了。
还有，请你说明实在delete那个指针时出错的。

[topikachu]

回一贴

问题源自一段简单的代码：

void main()
{
char *p = new char;
cin>>p;
cout<<p[2];
delete p;
}

在以上代码中，如果你输入:abcd，那么如你所望，你会看到"正确"的输出"c"。但是会有错误提示出现：
Debug Error!
Program: test.exe
DAMAGE: after Normal block(#64) at 0x003429f8

更离奇的是，如果将代码改为如下的代码：
void()
{
char *p = new char;
cin>>p;
cout<<p;
delete p;
}

如果只输入一个字符a，那么依然报错。是不是奇怪，分配了一个字符，输入了一个字符，那么错在哪里？ 注意，最开始那行Debug Error!说明这是在Debug编译模式下才有的提示，如果你换到release频道，那么此提示不再出现，你成功得到了"c"，仿佛程序一切正常。

一个奇怪的现象是，如果去掉delete p这条语句，这个运行时错误消失了，甚至你在debug模式下也看不到这个提示。 问题何在？

以前我遇到过这种情况，分析后归结为一个结论：在debug模式下系统有一定的机制侦测到内存的非法访问。然后就放过这个问题。这个结论说了等于没说，关键在于，这种机制的具体运做过程。这次我下了狠心，不入虎穴，焉得虎子。我决定追进源代码里边去。 把编译环境设置成debug模式，很显然，问题出在delete p上，在这条语句设置断点，按F5，程序运行到这条语句前自动暂停，然后按F11。

Welcome to the Source Code World!

首先来到DELOP.CPP文件中，这个文件短小精悍，只有一个函数
void __cdecl operator delete(void *p) _THROW0()
{ // free an allocated object
free(p);
}

没有任何有用的信息，那就继续追进free（p）里。 不一会，我们追到了DBGHEAP.C中，你从文件名可以看出，这是在debug模式下才能进入的文件。

最后在_CRTIMP void __cdecl _free_dbg（void * pUserData, int nBlockUse )中的这条语句
if (!CheckBytes(pbData(pHead) + pHead->nDataSize, _bNoMansLandFill, nNoMansLandSize))
_RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at 0x%08X.\n",
szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)],
pHead->lRequest,
(BYTE *) pbData(pHead));

前受阻。 是不是觉得这这模块巨可怕，呵呵，静下心来，很简单，因为有if存在，那么CheckBytes（）一定是执行某种检验，如果检验失败，调用_RPT3()函数 在MSDN中，对_RPT函数族有这样的解释：

Track an application''s progress by generating a debug report (debug version only).

_RPT3的作用就是产生一个错误报告。
好了，知道了这一点就足够了，它对我们来说没什么意义了。那么只剩下CheckBytes了，深呼吸几口，好了，让我们进去吧。
static int __cdecl CheckBytes(unsigned char * pb, unsigned char bCheck, size_t nSize)
{
int bOkay = TRUE;
while (nSize--)
{
if (*pb++ != bCheck)
{
_RPT3(_CRT_WARN, "memory check error at 0x%08X = 0x%02X, should be 0x%02X.\n",
(BYTE *)(pb-1),*(pb-1), bCheck);
bOkay = FALSE;
}
}
return bOkay;
}

你看到了，这个函数只调用了_RPT3，再也没有其他的调用，看来，我们到头了。 下面是微软的程序员为这个函数写的注释的一部分：
*Purpose:
* verify byte range set to proper value
*Return:
* TRUE - if all bytes in range equal bcheck
* FALSE otherwise

再明显不过了，这个函数检验一定范围的位是否设定为了正确的值(就是传进来的那么bCheck），如果正确，返回bOkay=TRUE,否则，返回bOkay=FALSE. 都挖完了，再也没有任何有用的信息，我们仍旧不知道微软是如何进行校验的，眼前依然一片黑暗。如果还有黎明的曙光，那么只能从传入的参数身上发出，呵呵，它们三肩负着我们的厚望啊。看看第一个参数unsigned char* pb。 if (*pb++ != bCheck)这条语句告诉我们要将pb所指内存地址的指与bCheck比较，那么我们还有最后一线希望：直接监视内存。

还记得我们在delete p;前设的断点吗？好，让我们重新开始调试，按F5，从控制台输入"abcd"，然后到这条语句前停止了，查看变量p的值，是0x00342c40，那好，打开vc监视内存的窗口memory，我们查看这个地址的值：


此后的内存情况不再用图片显示。只用红色标志的内存表示发生了变化的内存

看到了吗？你的宝贝"abcd"乖乖地躺在内存中，其后跟了一个0x00，那表示''\0''，字符串结束标志。一切都很正常，到底哪里出错了？难道是delete p用错了，而应该用delete[] p？try it,你会发现依然有相同的错误。

从这段内存中仍然看不出问题，仿佛一切风平浪静，其实是我们来晚了，在delete p前，内存早已经发生了翻天覆地的变化。 再一次重新进入程序，这次我们从一开始就监视内存。

00342C40 EE FE EE FE EE FE EE 铪铪铪.
00342C47 FE EE FE EE FE EE FE .

这是char *p = new char,执行前的内存。下面是执行后的:

00342C40 CD FD FD FD FD F0 AD 妄.
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

看不出什么问题，再往下执行吧：(cin>>p, 这次我们输入ab）

00342C40 61 62 00 FD FD F0 AD ab.瓠
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

ab正确地放进了内存中，而且你可以看到cin还体贴地在ab后为你放了一个''\0''

还是没有什么问题？再往下走就是cout<<p了，它不会改动内存，再往下就到了delete p，到那时一切都晚了。 没错，就是这一步，静静的内存中早已经翻江倒海。

还记得static int __cdecl CheckBytes(unsigned char * pb, unsigned char bCheck, size_t nSize)中的bCheck, nSize吗？ 如果当初你也监视变量的话，会发现bCheck = 253, nSize = 4。这就是这个内存侦测机制的命门。小时候喜欢看武打片，有一部叫做〈鹰爪铁布衫〉的，当时令我如痴如醉啊，看过的人一定还记得最后杀那老头的时候是先在他天灵上一拍，接着再在裤裆上捏一把，呵呵，bCheck就是天灵，nSize就是裤裆。

把253转换为16进制，是什么，没错，是FD。呵呵，别忙往下看，想一想，你找到真相了吗？ 再看一眼char *p = new char执行后的内存，你发现了什么？p指向0x00342c40那个字节的值为CD，这是属于你的内存，看看后边跟的是什么，不多不少，恰恰是4个FD，恰恰是nSize个bCheck！

这个侦测内存非法访问的机制现在已经被我们开膛破肚了。微软在你申请的空间后加上四个FD，如果你访问了你非法访问内存，那么这些内存的内容将被改变(有一个问题我没有解决，我不知道FD代表什么，望知道的兄弟教我)，在delete时，将检查由new产生的''\0''结束符后是否有连续四个字节都是FD，如果有证明没有发生非法内存访问，如果没有，那就该让_RPT3老兄出马了。
对于
char *p = new char;
cin>>p;
cout<<p;
delete p;

这段代码，如果只输入一个字符a，cin>>p执行后的内存为

00342C40 61 00 FD FD FD F0 AD a..
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

虽然你只用了你申请的内存，但是cin为了讨好你给你加那个''\0''，覆盖了一个FD，这样，delete时照样报错，如果你这样做
char *p = new char[2];
那么cin>>p后内存为

00342C40 61 00 FD FD FD FD AD a..
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

那么程序将不会报错。 四个FD就是内存的生死疆界，超过这个疆界，呵呵，听见远方传来的崩溃的声音了吗？ 到此，一切真相大白，山高月小，水落石出！

（尾声：以上所有内容皆来自笔者独立分析，其中难免有错，更甚者，也许我大错特错，压根就不是这样的机制。如果你发现其中有不正确的地方，请指出，谢谢，在下感激不尽）

[klmswt]

我怎么结不了贴子了，总是出现
“贴子回复次数大于跟给分次数”
怎么搞的

[klmswt]

to topikachu(皮皮) ：
谢谢你的分析，很详细。
从中学到不少东西。

[topikachu]

re： klmswt(塞北的雪)

不是我写的，不是我写的
我只是转了一个贴