使用 WinDbg 打印内存中的对象

发布于 2024-12-20 16:12:04 字数 178 浏览 2 评论 0原文

我有一个简单的 C++ 服务,它从文件中读取文本并通过网络发送它。随着时间的推移,该服务在客户站点的内存消耗会增加。在 QA 测试中没有观察到此类行为。

我想知道是否可以在任何给定时间提取内存中的所有字符串对象。

是否可以自动化此过程,以便我在不同时间从客户那里获取转储,并找出每次内存的大小或内容并比较结果。

I have a simple C++ Service which reads text from a file and sends it over the Network. Over time the memory consumption of this service increases at customer site. No such behavior is observed in QA testing.

I would like to know if it is possible to extract all the String Objects that are in the memory at any given time.

Will it be possible to automate this process such that I take dumps from customer at different times and find out sizes or contents of the memory at each time and compare the results.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

忆离笙 2024-12-27 16:12:04

对于 C++ 来说,答案是否定的(在 C# 中则不同)。在 C++ 世界中,如果您怀疑存在泄漏,则需要在“泄漏”发生之前在进程上启用用户模式堆栈跟踪(+ust 在 gflags.exe 中)。发生泄漏后,获取进程的转储并进行检查。要检查它(我假设您在此响应中使用本机 Windows 堆),您需要遍历堆结构以找出分配位置,然后检查堆栈回溯以获取最常见分配大小的样本。

例子。

  1. 在运行应用程序之前,请运行 gflags /i MyApp.exe +ust。这将设置注册表项,为操作系统提供有关如何处理进程 MyApp.exe 的特殊指令
  2. 运行程序并让“不良行为”发生
  3. 在不良行为很容易看到时收集进程的转储(越容易发现)是看,越容易找到)
  4. 在 Windbg
  5. !heap -summary 中打开转储并找到具有最大虚拟字节数的堆
  6. 第一列是您的堆句柄。使用您在上一步中找到的条目中的堆句柄并运行 !heap -stat -h -grp。这将列出给定堆中使用最多空间的堆分配。
  7. 现在我们知道哪个堆很大,以及最常见的条目的大小。我们知道需要一些地址,因此我们可以查看分配它们的调用堆栈。运行 !heap -flt s 。
  8. 最后一步(我们已经很接近了)。运行 !heap -p -a 。现在,您将获得堆栈回溯,了解生成此分配的代码路径。现在您可以返回代码并找出为什么它没有被释放。

For c++ the answer is no (In C# is a different story). In the c++ world, if you suspect you have a leak you would want to enable usermode stack tracing (+ust in gflags.exe) on the process before the "leak" occurs. The after the leak has occurred, get a dump of the process and examine it. To examine it (I have assumed you are using the native windows heap in this response), you will want to walk throught he heap structures to find out where the allocations are, then examine the stack backtrace for a sampling of the most common allocation size.

Example.

  1. Before you apps is running, run gflags /i MyApp.exe +ust. This sets up the regkey that provides the OS the special instructions for how to handle the process MyApp.exe
  2. Run the program and let the "bad behavior" occur
  3. Collect a dump of the process while the bad behavior is easy to see (the easier it is to see, the easier it will be to find)
  4. Open the dump in Windbg
  5. !heap -summary and find the heap with the larges Virtual Byte count
  6. The first colomn is your heap handle. Use the heap handle from the entry you found in the previous step and run !heap -stat -h -grp. This will list the heap allocations that are using the most space in the given heap.
  7. So we now know which heap was large, and the size of the entries that are the most common. We know need the address of a few so we can look at the call stack that allocated them. Run !heap -flt s .
  8. Last step (we are sooo close). Run !heap -p -a . You will now have the stack backtrace for what codepath generated this allocation. Now you can go back to your code and find out why this is not getting freed.
像你 2024-12-27 16:12:04

听起来你有内存泄漏。我只使用 Windbg 来调试托管应用程序。也许这个链接可以帮助您一点。

It sounds like you have a memory leak. I only uses windbg to debug managed applications. Maybe this Link can help you a bit.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文