追踪在 Windbg 中创建对象的堆栈跟踪
我正在尝试追踪 Windows 中 C++ 应用程序中的内存泄漏，并且我已经获得了该应用程序的内存转储，其中包含大量泄漏的对象。我使用 Windbg 通过执行以下操作来跟踪它们：
// Get heap stats
!heap -s
这显示了以下内容：
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
00150000 00000002 1024 272 272 20 2 1 0 0 L
00250000 00001002 64 24 24 9 1 1 0 0 L
00260000 00008000 64 12 12 10 1 1 0 0
003a0000 00001002 64 24 24 1 0 1 0 0 L
003d0000 00001002 392256 292256 292256 3 1 1 0 49 L
00bb0000 00001002 64 56 56 1 1 1 0 0 L
00c30000 00001002 64 32 32 7 1 1 0 0 L
-----------------------------------------------------------------------------
因此我可以看到堆 003d0000 包含泄漏对象，因此我使用：
// Get individual heap stats
!heap -stat -h 003d0000
其中显示：
heap @ 003d0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
98 105de3 - 9b7bec8 (61.59)
50 f052f - 4b19eb0 (29.75)
8 21829f - 10c14f8 (6.64)
2a0 881 - 1652a0 (0.55)
d0 a5e - 86c60 (0.21)
48 19a1 - 73548 (0.18)
c0 8f0 - 6b400 (0.17)
490 155 - 613d0 (0.15)
40 1300 - 4c000 (0.12)
20 1ff1 - 3fe20 (0.10)
7c 7e1 - 3d0fc (0.09)
28 120c - 2d1e0 (0.07)
8708 5 - 2a328 (0.07)
34 8f4 - 1d190 (0.05)
e0 1dd - 1a160 (0.04)
bb88 2 - 17710 (0.04)
f0 12b - 11850 (0.03)
30 45d - d170 (0.02)
10 b73 - b730 (0.02)
90 f4 - 8940 (0.01)
所以我有一个大小为 98 字节的对象泄漏，我可以追踪该对象的内容：
!heap -flt s 98
这表明：
<snip>
19f56c38 0014 0014 [01] 19f56c40 00098 - (busy)
MyApp!MyObject::`vftable'
<snip>
这是我对 Windbg 的了解耗尽的地方，我可以看到堆上的对象属于类 MyObject 但我如何找出位置这个对象被创建了？
任何帮助将非常感激！
谢谢， J
I'm trying to track down a memory leak in a C++ application in Windows and I've got a memory dump of the application with a large number of leaked objects. I'm using Windbg to track them down by doing the following:
// Get heap stats
!heap -s
This shows the following:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
00150000 00000002 1024 272 272 20 2 1 0 0 L
00250000 00001002 64 24 24 9 1 1 0 0 L
00260000 00008000 64 12 12 10 1 1 0 0
003a0000 00001002 64 24 24 1 0 1 0 0 L
003d0000 00001002 392256 292256 292256 3 1 1 0 49 L
00bb0000 00001002 64 56 56 1 1 1 0 0 L
00c30000 00001002 64 32 32 7 1 1 0 0 L
-----------------------------------------------------------------------------
So I can see that heap 003d0000 contains the leaking objects so I use:
// Get individual heap stats
!heap -stat -h 003d0000
Which shows:
heap @ 003d0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
98 105de3 - 9b7bec8 (61.59)
50 f052f - 4b19eb0 (29.75)
8 21829f - 10c14f8 (6.64)
2a0 881 - 1652a0 (0.55)
d0 a5e - 86c60 (0.21)
48 19a1 - 73548 (0.18)
c0 8f0 - 6b400 (0.17)
490 155 - 613d0 (0.15)
40 1300 - 4c000 (0.12)
20 1ff1 - 3fe20 (0.10)
7c 7e1 - 3d0fc (0.09)
28 120c - 2d1e0 (0.07)
8708 5 - 2a328 (0.07)
34 8f4 - 1d190 (0.05)
e0 1dd - 1a160 (0.04)
bb88 2 - 17710 (0.04)
f0 12b - 11850 (0.03)
30 45d - d170 (0.02)
10 b73 - b730 (0.02)
90 f4 - 8940 (0.01)
So I have a leak of an object 98 bytes in size, I can track down what that object is with:
!heap -flt s 98
This shows:
<snip>
19f56c38 0014 0014 [01] 19f56c40 00098 - (busy)
MyApp!MyObject::`vftable'
<snip>
This is where my knowledge of Windbg runs out, I can see that the object on the heap is of class MyObject but how do I find out where this object was created?
Any help would be very much appreciated!
Thanks,
J
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里是一个不错的简短教程。不过，您需要启用一些全局标志才能获取堆栈跟踪。此外，根据您的平台/配置，您可能会遇到不幸的问题。
Here is a nice, short tutorial. You need to enable some Global Flags to get the stack trace, though. Also, depending on your platform / configuration you may run into an unfortunate problem.
您还可以将其与 XPerf（来自 Windows Performance Toolkit）一起使用，并带有以下标志：
-heap -stackwalk HeapCreate+HeapAlloc+HeapRealloc。这将为您提供一个很好的分析器式分析，分析内存分配但未释放的位置。You could also use it with XPerf (from Windows Performance Toolkit), with the following flags:
-heap -stackwalk HeapCreate+HeapAlloc+HeapRealloc. That would give you a nice profiler-style analysis of where memory was allocated but not freed.