iOS EXC_BAD_ACCESS and Autorelease pool

[KnightWRX]

I'm having a hard time figuring this one out. I thought I had a class properly down and stable and now adding an instance of it to my view controller, the app suddenly exits after viewDidLoad (the class instance is allocated and inited in the view Controller's init routine, before loadView and viewDidLoad are called) because of a EXC_BAD_ACCESS (happens while none of my mine code is running, it's generated in the run loop). Commenting out the line that creates the instance of my class, every proceeds as normal.

Here is a backtrace :

#0  0x01383df5 in objc_release ()
#1  0x01384c60 in (anonymous namespace)::AutoreleasePoolPage::pop ()
#2  0x015b9ed8 in _CFAutoreleasePoolPop ()
#3  0x000349f9 in -[NSAutoreleasePool release] ()
#4  0x00392f78 in _UIApplicationHandleEvent ()
#5  0x01d7bfa9 in PurpleEventCallback ()
#6  0x016591c5 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#7  0x015be022 in __CFRunLoopDoSource1 ()
#8  0x015bc90a in __CFRunLoopRun ()
#9  0x015bbdb4 in CFRunLoopRunSpecific ()
#10 0x015bbccb in CFRunLoopRunInMode ()
#11 0x0038f2a7 in -[UIApplication _run] ()
#12 0x00390a9b in UIApplicationMain ()
#13 0x00002489 in main (argc=1, argv=0xbffff664) at /Users/username/Documents/Projects/projectname/main.m:36

What would be a good way to track this one down ? Is there a way to see objects that accumulate in the AutoreleasePool and know which it is trying to free that doesn't exist anymore ?

Searched around quite a bit on this one, tried many different things (and fixed a whole lot of leaks in my class in the process) and nothing seems to quite fix this one.

 

[chown33]

Run in instruments with zombies enabled.

Zombies should be able to narrow down any over-release, even from an autorelease pool. Think of it this way: autorelease transfers ownership to the pool object. The pool object performs a release later. If the object has already been over-released when the pool object performs its release, then a zombie should find it. You still have to track down who did the over-release, but at least you should know what the object is.

 

[KnightWRX]

Run in instruments with zombies enabled.

You're like 3 seconds too late, just tracked them all down using Instruments for Zombies. Seems most NSFoundation methods will add Arrays and Dictionaries created as copies to the autorelease pool and I don't need to release them myself. Who would have thought... maybe I should read a book on this whole Cocoa thing...

Searched for this crap all day, finally posted and out of sheer desperation tried 1 last google search and came up with this exact solution :

http://stackoverflow.com/questions/327082/exc-bad-access-signal-received

UPDATE: I now use Instruments to debug Leaks. From Xcode 4.2, choose Product->Profile and when Instruments launches, choose "Zombies".

Thanks anyway! And I'm really impressed with this instrument stuff. Never actually used a code profiler before. I need to get into this.

 

[chown33]

Technically, a leak is not an over-release.

A leak is an under-release. That is, an object that continues to live, despite no one having a reference to it. Leaks are safe. They just consume memory. Since there's no reference to a leaked object, it's impossible for them to cause problems (other than consuming memory).

An over-released object, however, is a completely different thing.

 

[KnightWRX]

Technically, a leak is not an over-release.

A leak is an under-release. That is, an object that continues to live, despite no one having a reference to it. Leaks are safe. They just consume memory. Since there's no reference to a leaked object, it's impossible for them to cause problems (other than consuming memory).

An over-released object, however, is a completely different thing.

I know, I understand that. I was searching for these over releases, but couldn't figure out what I was releasing that I shouldn't be. ([NSDictionary dictionaryWithDictionary]'s reference documentation didn't seem to hint you didn't have to release it and logically, it was allocating a new one and copying the data from the old one, so boom, I was releasing it when done, same for a bunch of NSArrays created by the [NSDictionary allKeys] method).

But I did fix some of my own leaks (objects I was allocating and not releasing after their lifetime was done) in the process (which I know had nothing to do with the issue, just checking out the MM in my class).

 

[chown33]

I know, I understand that. I was searching for these over releases, but couldn't figure out what I was releasing that I shouldn't be. ([NSDictionary dictionaryWithDictionary]'s reference documentation didn't seem to hint you didn't have to release it and logically, it was allocating a new one and copying the data from the old one, so boom, I was releasing it when done, same for a bunch of NSArrays created by the [NSDictionary allKeys] method).

The hint is the method name. It follows the normal naming rule.

Logically, the purpose of having a uniform rule is to avoid having to state the behavior at every method description. The only time you'll see a hint or a statement is when a method doesn't follow the rule.