如何解释仪器中的Allocations和VM Tracker的结果？

Question

我正在跟踪一个非常严重的内存泄漏(或更可能是被遗弃的内存)情况.我做以下事情:

1)启动我的应用程序
2)到达应用程序将显示泄漏的点
3)使用'分配'选项启动仪器
4)附加到我的进程并开始记录
5)获取
初始快照6)拍摄初始快照VM跟踪器
7)重现导致内存上升的步骤
8)获取另一个快照
9)使用VM跟踪器获取另一个快照

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

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

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

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

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

Answer 1

不是直接答案 - 但 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/

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