PDA

View Full Version : Memory Leakage with Core Data Utility Tutorial




BadWolf13
Sep 16, 2010, 05:23 PM
Ok, I'm doing the core data utility tutorial found here:

http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/CoreDataUtilityTutorial/Articles/00_introduction.html#//apple_ref/doc/uid/TP40001800-CH202-TP1

And for some reason, when I run it, I get the following error message all through the console.

2010-09-16 18:07:32.951 CoreDataUtility[11269:a0f] *** __NSAutoreleaseNoPool(): Object 0x100107170 of class NSCFDictionary autoreleased with no pool in place - just leaking

I've got garbage collector set to "Required", and I put in the line:

objc_startCollectorThread();

At the beginning of the main function, so I have no idea what the problem is. Anyone else come across this?



jared_kipe
Sep 16, 2010, 06:19 PM
autorelease is different from garbage collection.

I suspect this is a somewhat generic message for autoreleasing a method without an autorelease pool. With garbage collection on, it shouldn't "leak".

BadWolf13
Sep 16, 2010, 06:48 PM
autorelease is different from garbage collection.

I suspect this is a somewhat generic message for autoreleasing a method without an autorelease pool. With garbage collection on, it shouldn't "leak".

That would be the exact reason for my question. I've used garbage collection in apps of my own devising, without this error EVER appearing, so I'm questioning why it's occurring this time.

BadWolf13
Sep 21, 2010, 11:20 AM
I have to be a bother with this, but doesn't anyone have any ideas about this? I really have trouble believing that there's a "generic" error message, especially when the documentation says that the memory leakage issue was fixed with a revision.

Krevnik
Sep 21, 2010, 03:55 PM
That's just it though, it is a generic error message. But you have to think this through in order to get to the right conclusion that will help you. The clues are all there, and unfortunately, you have to take the investigation over to find out exactly what went wrong. We simply don't have the access to your project.

So first off, what is the behavior of calling autorelease in a GC'd environment? Reading through the docs says it is short-circuited. This means that error shouldn't even appear (no code would be run that could even call NSLog like is happening here). That's your first clue that something is wrong. This binary is not running with GC required as it should.

So what are the next steps here? Well, there has to be some investigation on why the binary isn't building GC required. A couple things off the top of my head that have bitten me in the past are this: 1) If you set a value for one build flavor and only that one, and then build another, you will run into weird behaviors like this one. 2) XCode's incremental build sometimes gets false positives and will use the build cache when it shouldn't. In this case, the answer is to clean the project and rebuild.

As for the error? This is really what it says on the tin, and is common for developers who don't use GC while they are tweaking some piece of code. Autorelease was called on an object outside of an autorelease pool. Because your main thread has no autorelease pool, running the binary in a way with the GC as "supported" or off will hit this.

MorphingDragon
Sep 21, 2010, 06:53 PM
Are you on OSX 10.6? Clang/LLVM has more verbose error messages than GCC, you can see if Clang helps.


Try "Clean All", its in the build menu.

Krevnik
Sep 21, 2010, 06:57 PM
Are you on OSX 10.6? Clang/LLVM has more verbose error messages than GCC, you can see if Clang helps.

Try "Clean All", its in the build menu.

The error he reported is from the console log (runtime), not GCC. Clang won't really help make the Cocoa framework more verbose. :P

BadWolf13
Sep 22, 2010, 12:15 AM
Ok, thanks for the advice, as I checked the garbage collector status, I discovered that the project settings are different for the release and debug versions, and oddly enough, it defaults to release version. So thanks for all your help everyone.

MorphingDragon
Sep 22, 2010, 01:36 AM
The error he reported is from the console log (runtime), not GCC. Clang won't really help make the Cocoa framework more verbose. :P

Shh! Clang will make you coffee, no exceptions.

Krevnik
Sep 22, 2010, 02:21 PM
Ok, thanks for the advice, as I checked the garbage collector status, I discovered that the project settings are different for the release and debug versions, and oddly enough, it defaults to release version. So thanks for all your help everyone.

Good that you found it.

Shh! Clang will make you coffee, no exceptions.

Not that I have anything against Clang. The compiler errors are more useful than GCC's. :)