我在Visual Studio 2008下调试一个(本机)多线程C++应用程序.在看似随机的场合,我得到一个"Windows触发了一个断点......"错误,并注意到这可能是由于堆.这些错误并不会立即使应用程序崩溃,尽管它很可能会在之后崩溃.
这些错误的一个大问题是它们只在实际发生损坏后弹出,这使得它们很难跟踪和调试,尤其是在多线程应用程序上.
什么样的事情会导致这些错误？
我该如何调试它们？
提示,工具,方法,启发......欢迎.
我正在研究破坏堆的多线程 C++应用程序.找到这种腐败的常用工具似乎不适用.源代码的旧版本(18个月之前)表现出与最新版本相同的行为,因此这已经存在了很长时间并且没有被注意到; 在缺点方面,源增量不能用于识别何时引入错误 - 存储库中存在大量代码更改.
崩溃行为的提示是在这个系统中产生吞吐量 - 数据的套接字传输,它被导入内部表示.我有一组测试数据会定期导致应用程序异常(各种地方,各种原因 - 包括堆分配失败,因此:堆损坏).
行为似乎与CPU功率或内存带宽有关; 机器越多,崩溃就越容易.禁用超线程核心或双核核心可降低(但不消除)损坏的速度.这表明与时间相关的问题.
现在这里有一个问题:
当它在一个轻量级的调试环境下运行时(比方说Visual Studio 98 / AKA MSVC6),堆损坏相当容易重现 - 在事情失败和异常失败之前经过十或十五分钟,就像alloc;在复杂的调试环境下运行时一样(Rational Purify,VS2008/MSVC9或者甚至是微软应用程序验证程序)系统变得内存速度受限并且不会崩溃(内存限制:CPU没有达到上面50%,磁盘指示灯不亮,程序运行速度快,盒子消耗1.3G2G RAM) .因此,我可以选择能够重现问题(但不能确定原因)或能够识别原因或我无法重现的问题.
我目前最好的猜测是下一步是:
E6550 Core2 Duo); 这样可以在强大的调试环境下运行时重现崩溃导致错误行为; 要么new并delete使用VirtualAlloc并VirtualProtect在完成后将内存标记为只读.运行MSVC6并让操作系统捕获正在写入释放内存的坏人.是的,这是绝望的标志:谁是地狱重写new和delete？!我想知道这是否会使它像Purify等人一样慢.而且,不是:内置Purify仪器的运输不是一种选择.
一位同事刚刚走过去问"Stack Overflow？我们现在收到堆栈溢出了吗？!？"
现在,问题是:我如何找到堆腐败者？
更新:平衡new[],delete[]似乎已经有很长的路要走解决问题.而不是15分钟,应用程序现在大约两个小时崩溃.还没有.还有什么建议？堆损坏仍然存在.
更新:Visual Studio 2008下的发布版本似乎要好得多; 目前的怀疑依赖于STL随船携带的实施VS98. …
我正在尝试编写一个小的内存泄漏检测工具。
我的想法是跟踪应用程序中的动态内存分配寿命，以确定可能导致我的应用程序在使用过程中成为核心的任何无效的内存访问或未删除的内存。
我想编写一个简单的接口来覆盖new和delete。
在我的覆盖下，new我想打印功能行地址等，然后调用标准new。
有没有人尝试过？我不确定我是否可以从班级特定的新运算符中调用标准新。