我正在跟踪一个非常严重的内存泄漏(或更可能是废弃的内存)情况。我执行以下操作:
1)开始我的申请
2)到达应用程序将显示泄漏的地步
3) 使用“分配”选项启动工具
4)附加到我的进程并开始记录
5) 进行初始 heapshot
6) 使用 VM 跟踪器拍摄初始快照
7)重现导致内存上升的步骤
8) 再拍一张
9) 使用 VM 跟踪器拍摄另一个快照
如果我执行这些步骤，我会看到实际上没有意义的结果。我希望我遗漏了一些关于这些工具如何工作的信息。例如，我知道“泄漏”工具不会跟踪所有类型的内存分配(例如碳应用程序)。我的应用程序是一个巨大的遗留应用程序，它可能在我不熟悉的一些过时的子系统中具有奇怪的分配代码。也就是说，这就是我所看到的:
那么MALLOC_SMALL怎么会从72MB增长到224MB，而heapgrowth却只有45MB呢？分配工具是否缺少 VMTracker 正在记录的内容？
进一步支持我在分配工具中遗漏了一些东西......如果我查看 MALLOC_SMALL 下列出的新区域(那些不在第一个快照中，但在第二个快照中)，这些地址应该对应于分配的页面并考虑到 72MB->224MB 的差异，对吗？然后，我记住了该区域的地址范围(例如，0x79000000-0x7b000000)，然后返回到分配工具并按地址对“所有对象”列表进行排序。然后我寻找该范围内的地址。但是，我只看到 4 个分配只占 4KB？! VM 跟踪器在该区域报告的其他 32MB 在哪里？
任何帮助将不胜感激....我希望它是关于这些工具如何工作的基本知识，我只是不理解。
最佳答案
不是直接的答案 - 但 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/
里面有一些很好的信息......
关于performance - 如何解释仪器中分配和 VM 跟踪器的结果？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4024408/