Memory leak in Cocoa newly created application when using Garbage Collection?

Question

I decided to use GC for memory management for my last Cocoa project, and I found something interesting - if I create a new Cocoa application project in Xcode, turn on GC for support or it is required (I tried both), build and run it, it leaks It shows memory leaks!

Basically a large number of small leaks of objects like NSCFData, GeneralBlock, CGEvent, CFDictionary, CGSRegion, etc.

Steps to play:

• File-> new project → Cocoa application
• Project-> Change project settings-> GC Required (or one is supported)
• Build-> Build
• Run-> Run with performance tool-> Leaks
• Wait until it detects a leak (I set it to 10 seconds, by default it is 30)

In 80% of cases, I get a leak of about 2-20 Kbytes of various objects listed above.

Does anyone have any other similar behavior?

---

EDIT: I checked the following circumstance by renaming the InputManagers folder (after which the log messages went away so that they definitely stopped loading) and I still get memory leaks. Therefore, it seems that this has nothing to do with it. I leave the text there, so Ashley Clark's answer still makes sense.

The only strange circumstance that I know if I get the following message in the console every time I start the application 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 

which, I suppose, has something to do with the two plugins that are loaded into each running program, and not just Safari (for which they are intended for plugins). I'm not sure if there is anything or not with this, but it definitely looks like an opportunity. I don't have convenient access to clean, not OS X 10.5, with Dev tools to check if this happens on a virgin installation without SAFT or Inquisitor.

Answer 1

The leaks tool is not accurate in Leopard's Objective-C garbage collection because it does not know enough about the garbage collector runtime structures to actually determine which objects still exist but are ready to be returned.

In addition, you are a little mistaken in your interpretation of the leaks results: what looks like a leak does not come from NSCFData, CGEvent, etc. - These are supposedly leaked objects.

The info gc-references and info gc-roots commands in GDB are what you want to use if you think certain objects have been living in Objective-C garbage collection for too long. Bill Bumgarner discusses them along with the general concept of "leaks" under the GC in this post before Cocoa -Dev .

Answer 2

These log messages tell you that Inquisitor.bundle and SaftLoader.bundle are not designed to work in GC programs and therefore do not load. Although they can only be designed for Safari, they are input managers, which means that every Cocoa application tries to load them at startup, so an incorrectly written input manager can cause a lot of problems.

I doubt that they are responsible for what you see, but if you want to test without them, just rename the InputManagers folder before running your tests and they will be ignored.

Where do you see these leaks?