C++ 程序稳定运行一段时间后异常中止，为什么？vc6 运行库的bug!!!

最近发现Visual C++ 6.0有一个有趣的，能让programmer发疯的bug。Debug版本编译出来的程序可能最终会异常中止，也许是报告程序停在断点xxxxxxx。更确切地说是用debug 版本的运行时库编译的程序。 

由于项目需要写了一个求最短路径的引擎。 运行稳定（内存，CPU，Handle count 保持未定），但是一段时间后，进程突然退出（crash?）。确切地说是计算了20000+ 对（源点、目标点）后。没有捕捉到任何异常。就好像有人杀掉进程似的。通过分析在Adplus在进程退出前创建的进程dump，发现是CTRL+C导致进程退出，堆栈信息显示计算线程最后调用函数是_heap_alloc_dbg。 这个函数是被由new 或者malloc调用的。

难道是out of memory？可是performance monitor 现实内存稳定，并没有泄漏。仔细分析dump，发现程序最后一个语句是dbgheap.c的338 行

if (lRequest == _crtBreakAlloc)   //337
            _CrtDbgBreak();                //338

根据msdn，_CrtDbgBreak 用来设定断点。为什么呢？阅读_heap_alloc_dbg函数发现：

　　lRequest = _lRequestCurr;

        /* break into debugger at specific memory allocation */
        if (lRequest == _crtBreakAlloc)
            _CrtDbgBreak();

        //省略如干行
        ++_lRequestCurr;

也就是说一旦_heap_alloc_dbg被调用，_lRequestCurr就增加１，搜索_lRequestCurr和_crtBreakAlloc，发现定于如下：

static long _lRequestCurr = 1;
_CRTIMP long _crtBreakAlloc = -1L;

并且只有函数_CrtSetBreakAlloc改变_crtBreakAlloc 。在我的程序中没有地方调用_CrtSetBreakAlloc，所以_crtBreakAlloc 应该保持-1，所以只要_heap_alloc_dbg, 也就是说new 或malloc被不停的调用，即使请求的内存被正确释放，条件lRequest == _crtBreakAlloc最终会满足。Yes, that's it!!!

写了一个简单的小程序如下，证实了我的想法。

int nCount = 1;
while(1)
{ 
   char* p = new char[4];    //cause _lRequestCurr to increase
   delete []p;
   nCount++;
   if(nCount == 0xffffffff)  //_lRequestCurr should reach this value already
 break;              //to ensure that if my thought is wrong, loop could break   
}

所以我认为这是debug run-time library的一个bug。如果程序（compiled with vc6 debug version run-time library）中会不停的请求内存，那么该程序最终会异常中止，只是时间问题。

所幸的是微软在以后的版本中对这个做了修改，vs2005中已经没哟这个bug了。具体不知道是从那个版本开始的。