问题描述
我决定在我最新的Cocoa项目中使用GC进行内存管理，我发现了一些有趣的东西 - 如果我在Xcode中创建一个全新的Cocoa应用程序项目，将GC转换为支持或需要（我试过两个） ，并且运行它泄漏，它显示内存泄漏！
I decided to use the GC for memory management for my latest Cocoa project, and I discovered something interesting--if I create a brand new Cocoa app project in Xcode, turn GC to supported or required (I tried both), build, and run it it leaks, it shows memory leaks!
大多数类型NSCFData，GeneralBlock，CGEvent，CFDictionary，CGSRegion等的对象的小型泄漏
Mostly large numbers of tiny leaks of objects of type NSCFData, GeneralBlock, CGEvent, CFDictionary, CGSRegion, etc.
重现步骤：
- File-> new project-> Cocoa app
- 项目 - >编辑项目设置 - > GC必需（或支持的任一项）
- Build-> Build
- 运行 - >使用效果工具运行 - >泄漏
- 等待泄漏检测触发（我设置为10秒，默认为30秒）
- File->new project->Cocoa app
- Project->Edit Project settings->GC Required (or supported, either one)
- Build->Build
- Run->Run with performance tool->Leaks
- Wait for leak detection to trigger (I have it set to 10 secs, it defaults to 30)
80％的时间，所以我得到了大约2-20 Kb的上述各种对象的泄漏。
80% of the time or so I get a leak of around 2-20 Kb of various objects of the sort listed above.
有没有其他人有同样的行为？
Does anybody else have this same behavior?
编辑：我测试了以下情况重命名InputManagers文件夹（在这一点日志消息消失了，所以他们绝对不再被加载），仍然获得内存泄漏。所以它似乎不可能与它有任何关系。我把文本留在那里，所以Ashley Clark的答案仍然有意义。
I tested the below circumstance by renaming the InputManagers folder (at which point the log messages went away, so they were definitely no longer being loaded) and am still getting the memory leaks. So it doesn't seem likely that had anything to do with it. I'm leaving the text there so Ashley Clark's answer still makes sense.
我知道的唯一奇怪的情况是，如果我在运行启用GC的应用程序时收到以下消息：
The only odd circumstance I know if is I'm getting the following message in the console any time I run an app with GC enabled:
2008-12-12 13:03:09.829 MemLeakTest[41819:813] Error loading /Library/InputManagers/Inquisitor/Inquisitor.bundle/Contents/MacOS/Inquisitor: dlopen(/Library/InputManagers/Inquisitor/Inquisitor.bundle/Contents/MacOS/Inquisitor, 265): no suitable image found. Did find:
/Library/InputManagers/Inquisitor/Inquisitor.bundle/Contents/MacOS/Inquisitor: GC capability mismatch
2008-12-12 13:03:09.840 MemLeakTest[41819:813] Error loading /Library/InputManagers/Saft/SaftLoader.bundle/Contents/MacOS/SaftLoader: dlopen(/Library/InputManagers/Saft/SaftLoader.bundle/Contents/MacOS/SaftLoader, 265): no suitable image found. Did find:
/Library/InputManagers/Saft/SaftLoader.bundle/Contents/MacOS/SaftLoader: GC capability mismatch
我猜这些两个插件试图加载到每个启动的程序，而不只是Safari（他们是插件）。我不知道这是否有任何做与这或否，但它绝对看起来像一种可能性。我没有方便地访问一个干净的，而不是OS X 10.5与开发工具，以测试是否这个相同的事情发生在没有SAFT或查询的原始安装。
which I'm guessing has something to do with those two plug-ins trying to load into every single program that starts, not just Safari (which they're plug-ins for). I'm not sure if that has anything do do with this or not, but it definitely seems like a possibility. I don't have convenient access to a clean instead of OS X 10.5 with Dev tools to test whether or not this same thing happens on a virgin install without SAFT or Inquisitor.
推荐答案
leaks 工具在Leopard的Objective-C垃圾回收中不准确，因为它不了解运行时垃圾收集器的结构实际上确定什么对象仍然存在，但准备被回收。
The leaks tool isn't accurate under Objective-C garbage collection in Leopard, because it doesn't know enough about the runtime structures of the garbage collector to actually determine what objects are still extant but ready to be reclaimed.
此外，你有点错误的解释的结果 leaks ：看起来像泄漏不是来自 NSCFData，CGEvent等等 - 这些是对象。
Also, you're a bit mistaken in your interpretation of the results of leaks: What look like leaks aren't coming from NSCFData, CGEvent, and so on — those are the supposed leaked objects.
info gc-references 和 info gc-roots GDB中的命令是你想要使用的，如果你认为特定的对象生活太长的Objective-C垃圾回收。 Bill Bumgarner在。
The info gc-references and info gc-roots commands in GDB are what you'll want to use if you think specific objects are living too long under Objective-C garbage collection. Bill Bumgarner discusses them along with the general concept of "leaks" under GC in this post to Cocoa-Dev.
这篇关于使用垃圾收集时，新创建的Cocoa应用程序中的内存泄漏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！