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

Question

我正在跟踪一个非常强硬的内存泄漏（或更可能是遗弃内存）的情况。我做到以下几点：

1）启动我的应用程序
2）获取到一个地步，应用程序将显示泄漏
3）使用“分配”选择
4）连接到我的过程开始仪器和开始记录
5）采取的初始heapshot
6）采取与VM跟踪
7）再现致使所述步骤的初始快照存储器上升
8）采取另一种heapshot
9）采取与VM另一个快照跟踪器

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

在VM跟踪器的初始快照，当我看着摘要
• ，类型MALLOC_SMALL是相当小的，在大约72MB（虚拟大小）在第二个快照
• ， MALLOC_SMALL使用率已经增长到224MB（再次虚拟大小）在第二heapshot
• ，它告诉我heapgrowth是45MB

那么，怎样才能从MALLOC_SMALL增长72MB 224MB的，但heapgrowth只有45MB？ Allocations乐器是否缺少VMTracker正在录制的内容？

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

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

Answer 1

不是一个直接的答案 - 但比尔布姆加纳最近的博客上讲述仪器的一些用途和内存增长：

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

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