Breakpoint pointing out “objc_autoreleaseNoPool”

Question

So I\'m debugging an app in preperation for its app so release, and I enabled a universal breakpoint for "All Exceptions". Since then, everytime I run the app, the co

Answer 1

It means you need to create an autorelease pool on the thread it happens. Otherwise, your allocated objects will not be destroyed (as suggested by the message). So, break/pause at the symbol, then walk up the stack to your thread (or program) entry and add an autorelease pool. That's all.

Answer 2

Many of the methods in the cocoa api return autoreleased objects. In particular, those methods that return an object that don't begin with init, such as [NSNumber numberWithLong:]. If you don't have an autorelease pool in place, those objects will be leaked. You can find more information on using NSAutoreleasePool in the documentation.

Answer 3

New Info

I determined where my issue lies by creating a swizzled autorelease method.

I dont recommend doing that unless you know what you are doing, however this is what I found out.

+ (void) load; //Method is called outside the original autorelease pool.
+ (void) initialize; // Method is called outside the original autorelease pool.

NSThread creates its own thread, the called method should be wrapped in an autorelease pool.

Grand Central Dispatch takes care of adapting over the autorelease pool when using the "dispatch_..." commands. however, when you dispatch manually. you may want to wrap it in an autorelease pool.

Also, ARC does not handle letting you know that an autorelease will happen outside a pool.

Therefore if you are using ARC and know that you will be outside the autorelease pool. And there is nothing you can do about that. You will want to avoid all convenience methods.

use this.

[[NSString alloc] initWithFormat:@"%@",myObject];

instead of this

[NSString stringWithFormat:@"%@",myObject];

this will allow the arc system to retain and release, but the underlying autorelease done by the convenience method will be skipped as you will not have used the convenience method.

Hope that helps.

Original Answer

Ok, I dont feel this question was answered with enough detail.

the message being presented was

objc[1310]: Object 0x34f720 of class SimpleKeychain autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug

The debugger is pointing out a possible breakpoint that will help you debug the situation. Now while this breakpoint really did little to help debug the situation. I think that it is important to know how to add that breakpoint to the debugger and so I spent the time tinkering with it (after scouring the internet and finding nothing) until I got it to break on that error.

It is kind of annoying that break on all errors does not catch this, but here are the steps to add the breakpoint to the debugger.

first thing you want to do is select the debugger's breakpoint navigator

by clicking on this tab

next you look toward the bottom of the navigator pane and press the Plus button

This will allow you to manually add a breakpoint.

I selected a C++ breakpoint and entered the message name into the name text field.

after adding this exception it did in fact break.

However this may or may not be useful to you as an objective c developer. This broke into the Assembly code.

Unfortunately it only showed this point on the call stack for the thread.

And it turned out that the autorelease problem was because a class called autorelease in a dispatch_once call. and further investigation revealed that the +(void)load; method on the class was called before anything else. this is done via the call_load_methods function and is outside the thread on the main method.

to correct this, I merely added the autorelease pool wrapper around the call.

another solution may be to add the autorelease pool inside the +(void)load; method. but this was sufficient for my uses.

NOTE: I am adding this to the post here because I do not like finding an issue and not being able to figure out all paths to the resulting answer. If the debugger tells you to add a breakpoint to the function listed, then there should be some information somewhere to get that information. Hopefully this will lower the frustration of some of those out there trying to find this answer.