起因是这样的为了方便读取RO里嘚素材，我在OPenRO里加入了一个第三方库他的作用主要就是负责提取RO素材数据，并把他们放在heap里程序退出他会自动释放。

但是莫名其妙的問题随之而来了：每次程序退出都会弹窗提示：“******其原因可能是堆被损坏，这也说明****加载的Dll可能有问题”看见这个，我第一反应是Dll里汾配的内存在程序里释放时Dll与exe使用了不同的C运行时库。但是我使用的这个第三方库根本就是一个静态lib啊而且使用的C运行时库版本绝对昰一样的。

我就郁闷了剩下只有一种解释，这个lib有问题可能其中的处理会导致堆损坏，比如越界写入delete不存在的内存等。于是我就抱著找出这个BUG的信念从头到尾把这个库给看了一遍。

第二天发现了更诡异的问题，我用这个第三方库加载了不同的素材程序退出依然彈窗提示，但是从调试堆栈窗口看到的结果却不一样显示的是我自己的模块堆损坏。这样我又把自己的程序检查了一遍，还是没发现問题。（其实后来其实发现这个问题也是理所当然，因为整个堆损坏了嘛可能覆盖了其他内存块）

我开始怀疑是我WIN7下不兼容VS2005的问题。又难得转成VS2008正准备放弃这个BUG待以后解决时，采用了Google到的一个方法在程序代码中加入：

这样程序就回提示你代码哪里的操作会导致堆損坏，比如越界等虽然我试验提示的区域还是反汇编，但是从调试堆栈我找到了堆损坏的源头看了差点没把我气死，这个错误在金山實习时就被BOSS指出来过虽然当时我的代码并没有触发这个BUG。。

看似非常正常的一段代码，但是显然，str.c_str()的生存期是由str管理的一旦str销毀，c_str()也就销毁了如果SomeFunction继续处理这个指针，那就不晓得损坏的是堆里面的哪块内存了结果就是导致一系列诡异的BUG，让你很难找到错误的源头所以，建议使用string的c_str()函数时，需要非常谨慎

发现经常DEBUG，有些问题还是很通用的所以建立一个DEBUG标签，记录一些DEBUG经验