如何解释仪器中分配和 VM 跟踪器的结果?

发布于 2024-09-29 07:24:34 字数 927 浏览 6 评论 0原文

我正在跟踪一个非常严重的内存泄漏(或更可能是废弃的内存)情况。我执行以下操作:

1)启动我的应用程序
2) 达到应用程序显示泄漏的程度
3) 使用“分配”选项启动工具
4)附加到我的进程并开始记录
5) 进行初始堆快照
6) 使用虚拟机跟踪器拍摄初始快照
7)重现导致内存上升的步骤
8) 再拍一张照片
9)使用虚拟机跟踪器拍摄另一个快照

如果我执行这些步骤,我会看到没有真正意义的结果。我希望我错过了一些有关这些工具如何工作的信息。例如,我知道“泄漏”工具不会跟踪所有类型的内存分配(例如碳应用程序)。我的应用程序是一个巨大的遗留应用程序,在一些我不熟悉的过时子系统中可能有奇怪的分配代码。也就是说,这就是我所看到的:

  • 在 VM 跟踪器的初始快照中,当我查看摘要时,类型 MALLOC_SMALL 相当小,大约为 72MB(虚拟大小),
  • 在第二个快照中,MALLOC_SMALL 使用量已增长到 224MB(同样是虚拟大小) size)
  • 在第二个堆图中,它告诉我堆增长是 45MB

那么 MALLOC_SMALL 如何从 72MB 增长到 224MB,但堆增长只有 45MB?分配工具是否缺少 VMTracker 正在记录的内容?

进一步支持我在分配工具中遗漏了一些内容...如果我查看 MALLOC_SMALL 下列出的新区域(不在第一个快照中,但在第二个快照中的区域),这些地址应该对应于分配的页面并考虑到 72MB->224MB 的差异,对吗?然后,我记住了该区域的地址范围(例如,0x79000000-0x7b000000),然后返回分配工具并按地址对“所有对象”列表进行排序。然后我寻找该范围内的地址。但是,我只看到 4 个分配,仅占 4KB?! VM 跟踪器报告的该区域中的其他 32MB 在哪里?

任何帮助将不胜感激......我希望这是关于这些工具如何工作的基本知识,但我只是不理解。

I am tracking a very tough memory leak (or more likely abandoned memory) situation. I do the following:

1) start my application
2) get to a point where the application will show the leak
3) start instruments using the 'allocations' choice
4) attach to my process and start recording
5) take an initial heapshot
6) take an initial snapshot with VM tracker
7) reproduce the steps that cause the memory to rise
8) take another heapshot
9) take another snapshot with VM tracker

If I do those steps, I see results that don't really make sense. I am hoping that I am missing some information about how these tools work. For example, I know that the 'leaks' tool doesn't track ALL kinds of memory allocations (carbon apps for example). My application is a huge, legacy app that could have weird allocation code in some out dated subsystem that I am not familiar with. That said, this is what I see:

  • in the initial snapshot of VM tracker when I look at the summary, the type MALLOC_SMALL is fairly small at roughly 72MB (virtual size)
  • in the second snapshot, MALLOC_SMALL usage has grown to 224MB (again virtual size)
  • in the second heapshot, it tells me the heapgrowth is 45MB

So how can MALLOC_SMALL grow from 72MB to 224MB, but the heapgrowth is only 45MB? Is the Allocations instrument missing something that VMTracker is recording?

Further supporting that I am missing something in the Allocations instrument...if I look at the NEW regions listed under MALLOC_SMALL (ones that weren't in the first snapshot, but were in second), those addresses should correspond to pages that were allocated and account for the 72MB->224MB difference, correct? So then, I remembered the range of addresses for that region (eg, 0x79000000-0x7b000000), and go back to the Allocations instrument and sort of the list of 'All Objects' by address. Then I look for addresses in that range. However, I only see 4 allocations that account only for 4KB?! Where are the other 32MB that VM tracker reported in that region?

Any help would be appreciated....I am hoping it is something basic about how these tools work that I am just not understanding.

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

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

发布评论

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

评论(1

挽心 2024-10-06 07:24:34

不是直接答案 - 但 Bill Bumgarner 最近在博客中介绍了 Instruments 的一些用途和内存增长:

http://www.friday.com/bbum/2010/10/17/when-is -a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/

那里有一些很好的信息......

Not a direct answer - but Bill Bumgarner recently blogged about some uses of Instruments and memory growth :

http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/

There's some good information in there...

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