查找堆损坏
这是我上一个问题的延伸，应用程序崩溃，没有任何解释。
我遇到过很多崩溃，可能是由应用程序服务器上的堆损坏引起的。这些崩溃仅发生在生产中；它们无法在测试环境中重现。
我正在寻找一种方法来追踪这些崩溃。
建议使用应用程序验证器，它会很好，但它在我们的生产服务器上无法使用。当我们尝试使用应用程序验证程序在生产环境中启动它时，它变得非常慢，以至于完全无法使用，即使这是一个相当强大的服务器（64 位应用程序、16 GB 内存、8 个处理器）。在没有应用程序验证程序的情况下运行它，它仅使用大约 1 GB 内存，并且不超过任何处理器周期的 10-15%。
是否有其他工具可以帮助发现堆损坏，而不增加巨大的开销？
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.
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.
Are there any other tools that will help find heap corruption, without adding a huge overhead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 Microsoft 运行时库的调试版本。打开红色分区，并通过在初始化期间调用
_CrtSetDbgFlag()一次，每 128 个（例如）堆操作自动检查一次堆。_CRTDBG_DELAY_FREE_MEM_DF对于查找内存释放后使用的错误非常有用，但堆大小在使用它时会连续增长。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_DFcan be quite useful for finding memory-used-after-free bugs, but your heap size grows monitonically while using it.运行虚拟化并拍摄计划快照是否有任何好处，以便您希望可以在实际崩溃之前获得快照？然后拍摄崩溃前快照并在实验室环境中启动它。如果您可以让它再次崩溃，请重新启动快照并开始检查您的服务器进程。
Would there be any benefit in running it virtualized and taking scheduled snapshots, so that you hopefully can get a snapshot just a little before it actually crashes? Then take the pre-crash snapshot and start it in a lab environment. If you can get it to crash again there, restart the snapshot and start inspecting your server process.
Mudflap 与 GCC。它对生产代码进行代码检测。
您必须使用
-fmudflap编译您的软件。它将检查任何错误的指针访问（堆/堆栈/静态）。它设计用于生产代码，但速度会稍微慢一些（在 x1.5 到 x5 之间）。您还可以禁用读取访问检查以加快速度。Mudflap with GCC. It does code instrumentation for production code.
You have to compile your soft with
-fmudflap. It will check any wrong pointer access (heap/stack/static). It is designed to work for production code with a little slowdown (between x1.5 to x5). You can also disable check at read access for speedup.