CODEWITHSUNDEEP
multithreadingcocoadebuggingobjective-c++
Amitg2k12
Amitg2k12

Reputation: 3805

What does “Autoreleased with no pool in place” mean?

My Application structure is as follows, the core part is written in C++ and using thread heavily, and i am developing UI in Objective C on top of it, if i don't execute the thread it works fine, but i can't disable, stop thread, UI is crashing randomly in the log i could see , following message 

__NSAutoreleaseNoPool(): Object 0x350270 of class NSCFString autoreleased with no pool in place - just leaking

Similar messages coming more then once, by googling come to know, i need to set NSAutoReleasePool to get rid of it, but how its possible to integrate the same with C++ code.

Edit: Core lib will be activated from UI , hence i suppose, its safe to say UI is running in the main thread, Lib is creating/terminating thread without notifying UI, in this case, can i call AutoReleasePool in the UI

Can anyone guide me?

Upvotes: 8

Views: 7379

Answers (2)

Peter Hosey
Peter Hosey

Reputation: 96333

It means you autoreleased something without an autorelease pool in place.

Every thread has a stack of autorelease pools. On the main thread, an autorelease pool is created for you before Cocoa calls out to your code, and drained after your code returns. Every object you autorelease (whether explicitly or implicitly) goes into the pool, so that the pool will release it when the pool gets drained. When you create a thread, you have to create and drain an autorelease pool on that thread yourself. (Or just not autorelease anything, but that's practically impossible for any meaningful amount of code.)

If you ever decide to run your code under garbage-collection, you'll need to send the pool drain, not release, when you're done with it, for the pool to be useful. When GC is enabled, release and autorelease messages do nothing—they don't even go through. Your autorelease pool will respond to drain by poking the garbage collector, which is the nearest equivalent to releasing the objects that would have been in the pool.

The Memory Management Programming Guide for Cocoa has more information about autorelease pools, among other things.

Upvotes: 1

Ben Zotto
Ben Zotto

Reputation: 71008

See these docs for what you should know about multithreading with Cocoa: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html

It's OK to design your app like you have, but two things should be kept in mind:

  1. Life is simplest (and sometimes necessary) when UI controls like views (AppKit or UIKit) are manipulated on the main thread. You can use Foundation objects and some AppKit/UIKit objects on background threads, and some Foundation objects can be used from multiple threads.
  2. If you're using any Cocoa objects at all in background threads, you'll need to set up autorelease pools on those threads.

Like so:

- (void)backgroundThreadStart 
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    // do stuff

    [pool release];
}

That will fix your console errors, but you might have other issues that led to the actual crashing you were seeing.

Upvotes: 7

Related Questions