GFlags设置可以捕获堆损坏(页面堆除外)吗? [英] GFlags setting to catch heap corruption (other than Page Heap)?

问题描述

在一个生产站点上，我们的应用程序^(*)反复崩溃，但不可重复.分析崩溃转储可以清楚地表明这是堆损坏:崩溃位于不同的位置，但始终在kernel32!HeapFree/ntdll!RtlpLowFragHeapFree内部访问冲突. Win Dbg !analyze -v还报告了堆损坏.

On one production site our application^(*) crashes repeatedly, but non-reproducibly. Analyzing the crash dumps clearly shows that it's a heap corruption: The crashes are at different location, but always access violations inside kernel32!HeapFree/ntdll!RtlpLowFragHeapFree. Win Dbg !analyze -v also reports a heap corruption.

到目前为止，我们一直尝试使用

What we have tried so far is to run the application with the GFlags option Page Heap. The problem is that the memory overhead of Page Heap is such that the application won't operate anymore (hitting virtual memory limit for the 32 bit process).

因此，我们不能使用Page Heap .其他哪个标志添加将非常有用，这样我们要么

So, we cannot use Page Heap. Which other flags would be useful to add so that we either

• 在损坏站点上崩溃
• 还是至少可以从崩溃转储中获取更多信息，而崩溃转储最终将在我们崩溃时生成?

我们目前正在尝试标记:

We are currently trying out the flags:

• 启用堆标记
• 启用堆尾检查

• Enable heap tagging
• Enable heap tail checking

希望下一个崩溃转储将包含更多有关发生问题的信息.

in the hopes that the next crash dump will contain some more information of what went wrong.

我考虑了这些标志，但暂时将它们忽略了:

I considered these flags, but left them out for now:

• 启用堆参数检查 ...我希望系统在每次调用堆函数时都进行检查
• 启用无堆检查 ...不确定是否真的会给我买任何东西
• 启用堆验证呼叫 ...甚至这里的文档都警告高昂的费用

• Enable heap parameter checking ... I would expect quite some overhead when the system checks every time a heap function is called
• Enable heap free checking ... not sure whether this would actually buy me anything
• Enable heap validation on call ... here even the docs warn of the high overhead

我(也)遇到的一个问题是，我不确定在发生内存损坏时这些标志如何提供帮助.当在保护页面中写入内容时，页面堆显然会产生访问冲突，但是其他标志如何工作?

One problem I (also) have is that I'm unsure how these flags help when a memory corruption occurs. Page Heap obviously will generate an access violation when something writes into the guard pages, but how do the other flags operate?

我是否必须使用Application Verifier运行该应用程序才能获得其他标志的帮助?还是在检查代码检测到某些东西时引发异常?

Do I have to run the app with Application Verifier for these other flags to help? Or will an exception be raised when the checking code detects something?

哪种标记最有意义，以便应用程序仍然可以在生产中以良好的性能和内存消耗运行?

Which combination of these flags makes most sense so that the application can still run with OK performance and memory consumption in production?

_{(*):这是工业自动化中的32位Windows桌面应用程序.在这种情况下，可以在Win7 64bit上运行(在很多其他站点上也可以).}

_{(*) : It's a 32bit Windows desktop application in industrial automation. Running on Win7 64bit in this case (which it does just fine at a whole lot of other sites).}

推荐答案

恕我直言，控制所有这些检查的最简单方法是使用ApplicationVerifier. 您拥有一个完美的用户界面，并且可以使用所有标志.
1. 无堆检查是一个很好的标志，没有太多的开销.因此，如果对堆块进行了严重修改并且释放了该块，那么您将有机会进入调试器.如果损坏发生在块的分配和释放附近，则可能会有所帮助.
2. AFAIK堆参数检查"只是一个轻量级的调用堆验证".我从来没有成功.
3. 堆尾检查和标记非常容易且快速.有时对我有用.

1. IMHO the easiest way to control all this checking is using the ApplicationVerifier. You have a perfect UI and you can play around with all flags.
2. Heap Free checking is a good flag without too much overhead. So if a heap block is badly modified and the block is freed you get a break into the debugger. If the corruption occurs near the allocation and freeing of the block, this might help.
3. AFAIK "Heap parameter chechking" is just a lightweight "heap validation on call". I never had any success with this.
4. Heap tail checking and tagging is easy and fast. Works sometimes for me.

您知道您也可以使用gflag在每个应用程序的基础上进行控制.

You know that you can control this on a per application base also with gflags.

gflags.exe/i Testapp.exe e0

但是:查找此类问题的最佳方法是完全使用Debug-CRT ...(如果可能).因此，如果有机会在生产环境中使用您的Debug-Version，请执行此操作. 在Debug-CRT内部，您再次可以使用和设置许多标志....

But: The best way to find such problems is completely using the Debug-CRT... if it is possible for you. So if there is a chance to use you Debug-Version in the production environment, do it. Inside the Debug-CRT you again a lot of flags you can use and set....

这篇关于GFlags设置可以捕获堆损坏(页面堆除外)吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！