Garbage Collector + KnM Plugs

franz's picture

Hi there !

I'm developing some app, that bundles KnM free plugs - for a better portability - and i would like to use garbage collector within my project. Right now, i've got some objects leaking, like :

2009-03-12 21:39:54.156 Gueb.V.L.R[2548:b43f] *** _NSAutoreleaseNoPool(): Object 0x5c7130 of class NSURL autoreleased with no pool in place - just leaking

2009-03-12 21:39:55.059 Gueb.V.L.R[2548:b43f] *** _NSAutoreleaseNoPool(): Object 0x178a4df0 of class NSCFArray autoreleased with no pool in place - just leaking

yes, i know, that's pretty ugly ;(

I'm naively thinking that enabling Garbage Collector in the project settings would nicely clear all this mess -- as advertised, and eventually it will do me a coffee.

However, whenever i do this, KnM plugins do crack :

SpookyPatch: GC capability mismatch or Error Domain=NSCocoaErrorDomain Code=3586 UserInfo=0x10b6030 "The bundle “StructureTools” could not be loaded because it is not compatible with the current application." bla bla bla ...

I've tried the NSAutoReleasePool, however without success (nor failures, strangely...)

Any thoughts ?

cwright's picture
Re: Garbage Collector + KnM Plugs

That error happens because you're doing NSblahblah stuff outside of an NSAutoreleasePool -- it has nothing to do with GC.

you Really (as in, I promise) don't want to use GC with QC/CI stuff. http://developer.apple.com/releasenotes/GraphicsImaging/RN-CoreImage/ind...

Short version: Performance suffers, GC won't actually free images, and you'll run out of memory.

-retain, -release, and NSAutoreleasePool stuff all "work" with garbage collection, but they're essentially no-ops (they don't do anything). Kineme Plugins will throw an error because they're all compiled with GC set to unsupported. We could try re-compiling them for either GC/non-GC, but I'm not sure of the long-term stability of such a move. shrugs more to test I guess...

franz's picture
Re: Garbage Collector + KnM Plugs

ouch ! i guess i'll have to suffer more, and browse the cocoa book ( which is what i'm doing right now) thanks for your ultra-fast answer.

cwright's picture
Re: Garbage Collector + KnM Plugs

For the above error, that typically happens in only 2 places:

1) you've created a new thread (or some underlying framework does for you) -- CVDisplayLink stuff runs in separate threads, CoreAudio stuff runs in separate threads.

2) you're doing stuff in main() (before an autorelease pool gets created). NSApplicationMain makes one for you, so all your delegates should have one in place automatically.

franz's picture
Re: Garbage Collector + KnM Plugs

i don't think i'm creating a new thread - at least not explicitly- since i'm using QCviews (a couple to be precise).

Indeed, i'm doing stuff in Main - you are actually, since you modded my main to automatically load plugs. from the bundle.

Here's my main / (comment are yours) -- and sorry if that sounds uber-newbee-coder, but you're teaching me how to fish, somehow --

@interface QCPatch
+ (void)loadPlugInAtPath:(NSString *)pluginPath;
+ (void)loadPlugInsInFolder:(NSString *)pluginFolder;
@end
 
[code]
int main(int argc, char *argv[])
{
   NSAutoreleasePool *p = [ [NSAutoreleasePool alloc] init];
 
    // load plugins in our bundle's resource folder
    [QCPatch loadPlugInsInFolder: [ [NSBundle mainBundle] resourcePath]];
 
    int ret = NSApplicationMain(argc,  (const char **) argv);
    [p release];  // probably won't get here, but good practice
    return ret;
}

cwright's picture
Re: Garbage Collector + KnM Plugs

Do those messages happen continually, or just at startup?

If it's just at startup, I'm not sure exactly what's going on (your first statement creates an autorelease pool, so everything "should" be ok). If it's continual, then it's likely a thread thing.

Can you put an NSLog(@"here"); right after the autorelease line, and see if it gets printed before or after stuff starts spewing those messages?

franz's picture
Re: AutoReleasePool / semi-sorted !

After further inspection - thanks to your preceding comment - , it turned out that the problem was thread related.

I'm using the KnM QuickLook patch in ASYNCHRONOUS mode within the comp, so if i switch back to normal mode the problem is resolved.

wundebar !!!!

However, the execution of the patch stutters the output occasionally -- which is a bit annoying. Do you have a solution in mind , to allow me to use asynchronous mode again ? That would be sweet ....

cwright's picture
Re: AutoReleasePool / semi-sorted !

buggage -- that's actually a bug in filetools (where I forgot to wrap asynchronous quicklook generation in an autoreleasepool :() I should get an updated version out eventually to deal with that :/ [.lov. noticed this earlier I think]

in the mean time, it'll be ok in async, unless you let it run for a really long time (as it'll run out of memory eventually) -- I'll try to send you a pre-beta version with that fixed to get you on your way.

Thanks for tracking it down :)

franz's picture
Re: AutoReleasePool / semi-sorted !

" I'll try to send you a pre-beta version with that fixed to get you on your way. "

kewl, nice of you. btw, what do you mean by "a really long time " ? 1 week ? (of course it depends the amount of ram...)

cwright's picture
Re: AutoReleasePool / semi-sorted !

really_long_time = 2GB / (width * height * 4 * updates_per_second + some object overhead (not sure of the exact amount))

So basically: if you're doing a fixed number of quicklook previews (and the number is less than several thousand), you'll run forever (you'll leak a fixed amount). If you continue to generate thumbnails endlessly, you'll leak small amounts (width * height * 4+object overhead) each time, leading to exhausting memory.