查找堆损坏 [英] Finding heap corruption

问题描述

这是我上一个问题的扩展，应用程序崩溃，没有解释 。

This is an extension of my previous question, Application crash with no explanation.

我有很多崩溃，可能是由应用程序服务器上的堆损坏引起的。这些崩溃只发生在生产中;它们不能在测试环境中重现。

I have a lot of crashes that are presumably caused by heap corruption on an application server. These crashes only occur in production; they cannot be reproduced in a test environment.

我正在寻找一种方法来跟踪这些崩溃。

I'm looking for a way to track down these crashes.

应用程序验证者建议，这将是好的，但它不能使用我们的生产服务器。当我们尝试使用应用程序验证器在生产中启动它时，它变得如此之慢，以至于它是完全不可用的，即使这是一个相当强大的服务器（64位应用程序，16 GB内存，8个处理器）。运行它没有应用程序验证程序，它只使用大约1 GB的内存，不超过任何处理器的周期的10-15％。

Application Verifier was suggested, and it would be fine, but it's unusable with our production server. When we try to start it in production with application verifier, it becomes so slow that it's completely unusable, even though this is a fairly powerful server (64-bit application, 16 GB memory, 8 processors). Running it without application verifier, it only uses about 1 GB of memory and no more than 10-15% of any processor's cycles.

有任何其他工具，

推荐答案

使用Microsoft运行时库的调试版本。打开红色区域，并在初始化过程中通过调用 _CrtSetDbgFlag（）一次，在128个（说）堆操作中自动检查堆。

Use the debug version of the Microsoft runtime libraries. Turn on red-zoning and get your heap automatically checked every 128 (say) heap operations by calling _CrtSetDbgFlag() once during initialisation.

_CRTDBG_DELAY_FREE_MEM_DF 可以非常有用的找到内存使用后的免费bug，但是你的堆大小在使用它时单调增长。

_CRTDBG_DELAY_FREE_MEM_DF can be quite useful for finding memory-used-after-free bugs, but your heap size grows monitonically while using it.

这篇关于查找堆损坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！