我可以找到创建名为 OSMallocTag 的库吗？
我使用分配工具来测量 iOS 应用程序中的堆使用情况。我发现在标记名称为“Memory Tag 70”的区域中分配了大量内存，我想知道谁对此负责，以便我可以追查：
- 是否适合我尝试做任何事情 如果是的话
- ，我应该对此做什么（即什么代码在该区域分配对象）。
那么，我可以跟踪带有特定参数的 OSMalloc_tagAlloc() 调用来自何处吗？我愿意接受这样的事实：我可能只能在模拟器中运行时才能这样做，而不能在设备上运行。但即使是这样，我该怎么办呢？我可以让 dtrace 显示标签名称吗？如果可以的话，我可以通过 dtrace -c 在模拟器中启动我的应用程序吗？如何？
I use the allocations instrument to measure heap usage in my iOS app. I find that a significant amount of memory is allocated in a region with the tag name "Memory Tag 70", and I would like to know who is responsible for that so I can chase down:
- whether it's appropriate for me to try and do anything about this memory
- if so, what I should do about it (i.e. what code is allocating objects in that region).
So, can I trace where a call to OSMalloc_tagAlloc() with particular arguments is coming from? I'm willing to accept that I may only be able to do so when running in the simulator, not on the device. But even if that is the case, how would I go about it? Can I get dtrace to show me the tag names, if so can I launch my app in the simulator via dtrace -c? How?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在仪器中，您可以通过选择位于窗口顶部和底部之间的分隔线中的弹出窗口来在各种显示之间切换。对于“分配”，您可以将其切换为显示“调用树”（我认为它默认为“统计”）。
这应该为您提供所有分配的调用堆栈。然而我不确定它是否会从内核一直跟踪到用户空间。
In instruments you can switch between various displays by selecting the popup that sits in the divider between the top and bottom section of the window. For "Allocations" you can switch it to show "Call Trees" (I think it defaults to "Statistics").
This should give you call stacks for all allocations. I'm however not sure if it will trace all the way from kernel to user space.
对我来说，这个标签与我分配的大型 UIImages 相关。我做了一些调查，了解如何获得更多有关此问题的信息，并提出一些（也许）有用的建议。
我相信您感兴趣的标签是通过 vm_allocate 和类似的 flags 参数传递的标签，而不是 OSMalloc_tagAlloc() 。 iOS 3.1 发行说明提到了和;与 VM 仪器连接的标头。
我认为该标签是根据 vm_statistics.h 的 VM_FLAGS_ALIAS_MASK 和以下 #defines 通过 vm_allocate flags 参数传递的。 （它们在这里被称为“别名”。）这意味着您应该能够创建一个 dtrace 脚本来探测 vm_allocate，并从 flags 参数中提取标记。例如：
sudo dtrace -n 'fbt:mach_kernel:vm_allocate:entry /pid==12345/ { printf("%d", (arg3 & 0xFF000000) >> 24); 您可以使用 Instruments 制作 dtrace 仪器，并通过“仪器”菜单中的“构建新仪器...
”在 iOS 模拟器上运行，或者您可以使用命令行 dtrace 脚本并包含正在运行的应用程序的 /pid == 123456/ 谓词。
不幸的是，我未能成功找到正确的探测器来找到这些分配。当检查适当的 argN 变量时，标记/别名部分中的标志似乎总是为 0。例如，我尝试了上面的 fbt:mach_kernel:vm_allocate、fbt:mach_kernel:mach_vm_allocate、fbt:mach_kernel:vm_map_enter 等。也许这些分配正在通过其他途径？我对内核的内存分配系统了解不多。
所以，我不太确定这些标签是在哪里传递到内核的，但我希望这可以帮助您找到它。
For me, this tag was related to large UIImages I had allocated. I did some investigation into how you could get more information about this and have some (perhaps) useful things to suggest.
I believe that the tags you're interested in are the ones passed via the flags argument of vm_allocate and similar, not OSMalloc_tagAlloc(). The iOS 3.1 release notes mention the <mach/vm_statistics.h> and <mach/vm_map.h> header in connection with the VM instrument.
I think that the tag is passed via the vm_allocate flags parameter as per vm_statistics.h's VM_FLAGS_ALIAS_MASK and following #defines. (They're called "aliases" here.) This means you should be able to make a dtrace script that probes for, say, vm_allocate, and extracts the tag from the flags parameter. For example:
sudo dtrace -n 'fbt:mach_kernel:vm_allocate:entry /pid==12345/ { printf("%d", (arg3 & 0xFF000000) >> 24); }'You can use Instruments to make a dtrace instrument and run against the iOS simulator via "Build New Instrument..." in the "Instrument" menu, or you can use use a command-line dtrace script and include a /pid == 123456/ predicate for your running app.
Unfortunately, I was unsuccessful in finding the correct probe to find these allocations. When inspecting the appropriate argN variable, the flags always seems to have 0 in the tag/alia portion. I tried, for example, fbt:mach_kernel:vm_allocate as above, fbt:mach_kernel:mach_vm_allocate, fbt:mach_kernel:vm_map_enter, etc. Perhaps these allocations are going through some other avenue? I don't know much about the kernel's memory allocation system.
So, I'm not exactly sure where these tags are being passed to the kernel, but I hope this helps you track it down.