3

背景

我正在尝试追踪内存泄漏问题，我知道（从 _CRT_DEBUG_MALLOC 和 MFC 以及 CRT 的泄漏检测）内存泄漏的特定行，但由于该行经常被调用，我不知道是哪个调用实际上泄漏。并且分配编号 +__p__crtBreakAlloc()没有帮助，因为每次运行它都是不同的分配编号。

无论如何，到目前为止的背景。如果您认为我应该使用其他工具，请发表评论。如果答案集中在实际问题而不是我的潜在问题上，我将不胜感激，因为我发现这比泄漏本身更有趣（我最终会通过足够的戳来发现）。

问题

是否有可能在 WinDbg 中（我很确定它不在 VS 中）有一个具有以下属性的断点：

  • 它不会破裂。（所以它是一个“跟踪点”）
  • 命中时，记录调用堆栈（达到一定深度）
  • 它还应该记录一些全局状态（变量，可能只是内存地址的原始值）

这可能吗？如何？

4

3 回答 3

1

您正在尝试的是一种真正的蛮力方法，在处理内存泄漏时几乎没有积极影响 - 至少需要像 UMDH 这样的东西来应对基于堆栈跟踪跟踪泄漏的复杂性。即使您成功进行了一些跟踪，手动处理也可能过于冗长。

有一个通用的调试器扩展来跟踪各种泄漏，如果你走手动路线，这会给你一些杠杆作用：domdbg extension

我写了一个帮助 python 脚本，如果你走 UMDH 路径，你可能会发现它很有用 - 它可以帮助你自动拍摄快照，并且在分析跟踪时可以更有效，因为它会缓存符号信息并以二进制形式存储跟踪（与 UMDH 使用的文本表示相反）：pyumdh

于 2013-02-18T09:15:31.360 回答
1

还有一个跟踪器扩展可以跟踪任意打开和关闭操作。

于 2014-02-04T14:30:03.140 回答
1

要回答您的每个问题点：

  • 断点不中断：

    bp myDll!<namespace>::myClass::myFunc "gc"- 你可以执行用双引号分隔的命令，在这种情况下，当断点被命中时，只需继续

  • 在命中断点时将调用堆栈转储到一定深度

    .kframes 0n50; bp myDll!<namespace>::myClass::myFunc "kb;gc"- 这将调用堆栈长度设置为 50（默认为 20），0n告诉它我们是基于十进制的。双引号后的命令bp将转储调用堆栈，然后继续

  • 记录一些全局状态

    dt myVar- 将显示全局变量，另外将使用d* myVar

    dd myGlobalVar

    确保 pdbs 没有剥离私有符号 - 您应该检查信息，dt因为有特定的开关来处理 unicode 字符串、深度等。此外，您可以轻松地在WinDbg的监视窗口中观察值，另外请参阅有关文档d*

此外，WinDbg 中还有一个自动泄漏检测命令：

!heap -l

但我发现它有时有点命中注定，更多信息在这里

于 2013-02-16T23:16:09.487 回答