Breakpoint pointing out "objc_autoreleaseNoPool"

Go To StackoverFlow.com

16

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 console prints:

Catchpoint 2 (throw)Pending breakpoint 1 - "objc_exception_throw" resolved

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

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

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

Literally printed 3 times. I have no idea what this means but it looks bad. Any advice would be appreciated.

2012-04-04 01:49
by Andrew
do you have an autorelease pool? and check the app for leaks with one of the helper programs you can find in xcode (profile it - chikuba 2012-04-04 01:51
I don't use any autorelease pools. Truthfully, I don't understand why you would use one, so I never have. But I'll try tha - Andrew 2012-04-04 01:52
It shows up before the App del. finishes, But I commented out line by line the entire thing, and I am still leaking objects. Any thought - Andrew 2012-04-07 20:33


35

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

navigator toolbar

by clicking on this tab

breakpoint button

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

Add Exception Breakpoint

This will allow you to manually add a breakpoint.

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

Adding custom C++ exception

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.

assembly code at achieved breakpoint.

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

Thread list

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.

Error Call and Stack

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

updated error 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.

2012-06-05 20:31
by The Lazy Coder
Terrific answer. Thank you for taking the time to put together this post - Andrew 2012-06-13 02:44
Ditto. That breakpoint thing was a big help, even though my problem ended up being an entirely different on. Thanks for taking the time - Andy Milburn 2013-01-21 20:00
FYI, not sure if the exception name has changed or because mine was in an objc rather than an objc++ file, but I had to set the breakpoint to break on _NSAutoreleaseNoPool instead of objcautoreleaseNoPool. Hope that helps someone sometime. Original post was VERY helpful though - stuckj 2013-01-24 02:50
Thanks for the info on setting the breakpoint! Fortunately in my case the stack is showing me where the memory problem occurs - JohnK 2013-05-31 18:32


1

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.

2012-04-04 01:58
by highlycaffeinated
What does that mean? What can I do to fix this proble - Andrew 2012-04-04 01:59
Thanks. I'll look into i - Andrew 2012-04-04 02:10
just put one in the main where you start the app and you dont have to think about and just use the beauty that is auto-released objects : - chikuba 2012-04-04 02:14
chikuba, I'm getting the console messages before the app delegate finishes loading. But I can't find the right place to put the pool. Any suggestion - Andrew 2012-04-07 20:30
It shows up before the App del. finishes, But I commented out line by line the entire thing, and I am still leaking objects. Any thought - Andrew 2012-04-07 20:34


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.

2012-04-04 02:20
by justin
It shows up before the App del. finishes, But I commented out line by line the entire thing, and I am still leaking objects. Any thought - Andrew 2012-04-07 20:33
you have to add an autorelease pool. earlier in execution than the execution point where the breakpoint is hit. if it's on your main thread, then add an autorelease pool to int main() (note: your project template would have likely done this for you). otherwise, you would typically add it at your thread's entry - justin 2012-04-08 06:00
Ads