CODEWITHSUNDEEP
objective-cios5automatic-ref-countingexc-bad-access
danqing
danqing

Reputation: 3668

Obj-C message sent to deallocated object (EXEC_BAD_ACCESS), with iOS5, ARC

I'm developing an iOS5 App using ARC, and I started to get some random EXEC_BAD_ACCESS crashes that I cannot figure out.. By random I mean it is very unpredictable: sometimes it may take a long time to crash, sometimes short. and there is also no one specific button/tablecell/etc. that trigger the crash. Every user interaction can possibly crash the app, but you cannot repeat the crash.

I have tried to turn on NSZombie and also some malloc debugger tools. In Instruments the crash error reads: An Objective-C message was sent to a deallocated object (zombie) at address: 0x10bd1b40. And the last part of the reference count log looks like this:

475 CoursesFirstViewController  Release 2   02:23.253.631   0   UIKit   -[UINibDecoder finishDecoding]
476 CoursesFirstViewController  Release 1   02:23.253.838   0   Foundation  -[NSAutoreleasePool drain]
477 CoursesFirstViewController  Zombie  -1  02:35.752.420   0   Foundation  objectHash

The 2, 1, -1 thing are the reference counts. I have no idea why it skips 0 and drop to -1, crashing the program (all entries but the last have continuous ref counts). Also I have no idea what objectHash is.

My app comprises of multiple functions, accessible as icons on my main screen. CoursesFirstViewController is one of the functions. Always, it is CoursesFirstViewController and objectHash that crash the app, even if I am at somewhere else. (This is the case for the log above: I went out of CoursesFirstViewController (thus returning to the main screen of my app) at 02:23, but after 12 sec, when I was in some other function, the app crashed) I only need to enter CourseFirstViewController, mess around with it for a bit, and then go elsewhere to continue using the app, and after a while it will just crash.

I'm really mad of this problem now. I have searched SO and Google for quite a while but cannot find a solution. Any help will be greatly greatly appreciated. Thanks!!

Upvotes: 1

Views: 2627

Answers (3)

Rob Napier
Rob Napier

Reputation: 299355

@robmayoff yea I already checked that but didn't see anything especially useful there. the last few calls are objectHash, hashProbe, [NSConcreteHashTable rehashAround], [NSConcreteHashTable removeItem] etc.

This is actually somewhat useful. This is telling us that a collection, probably an NSDictionary, but possibly an NSSet is being destroyed. From your earlier information it seems to be an autoreleased collection that is created during the nib instantiation process (so probably an ivar of CoursesFirstViewController). That's where I'd be looking anyway given the symptoms, but the crash seems to confirm it.

General recommendations are auditing any __bridge casts or unsafe_unretained properties.

Another hunch is that you've named a method in a way that violates Cocoa memory management. The most likely misnaming would be that you have a property that starts with new or copy. This would definitely be an issue if you have ARC code call misnamed non-ARC code.

Upvotes: 2

rob mayoff
rob mayoff

Reputation: 385700

I gather from your Instruments output that the zombie object is of type CoursesFirstViewController. We often use a view controller as the delegate for some other object, and most objects that have delegates do not retain their delegates.

I am assuming that you aren't using any unsafe_unretained properties or variables, or any retain-type properties. So I assume that none of your objects is keeping a dangling reference to the CoursesFirstViewController zombie.

Since the system libraries have to work with non-ARC code, they do not use ARC's weak references. So if some system object has a CoursesFirstViewController as its delegate, and the CoursesFirstViewController is destroyed but the system object is not, then the system object is left with a dangling reference to the destroyed object.

So, check whether you're using the CoursesFirstViewController as the delegate for any system objects. If so, are you sure those objects don't outlive the CoursesFirstViewController?

Upvotes: 0

spoofwear
spoofwear

Reputation: 41

I suspect one of your properties is marked "weak" when it should be "strong" and is going out of scope and getting released before you access it. ARC can't save you in that case and you will get the above random crash behavior.

If you don't have any luck finding it I would resort to doing a global search for "weak" properties on your project and double-check each one to make sure it isn't something you expect to hang around. It's tedious but honestly doesn't take that long to do and sometimes turns up more than the one bug.

Upvotes: 0

Related Questions