ansaurus

Question

Messages to deallocated instance - failing gracefully

Answer 1

A:

If the object no longer exists and you don't want it to crash on sending a message to garbage (that is, if you have a pointer to a deallocated object and you send that pointer a message, resulting in a nasty crash), if you want to avoid that, set your pointer to nil after you release it. This signifies you are done with the object. Sending messages to nil is perfectly acceptable, but sending messages to pointed-at-garbage is not.

[iVar release];
iVar = nil; // done with this reference.

jbrennan 2010-07-09 05:38:28

That really won't work. If an object is deallocated, then you have to set every single reference to said object to `nil` which requires a level of knowledge of the object graph such that it becomes pointless to try and use such a solution.

bbum 2010-07-09 05:43:54

@bbum: that's a bit unfair (assuming it was you who downvoted). He only has to make sure that the pointer used by whatever handles the response is nil, which probably comes down to implementing some sort of "unregistering" code.

JeremyP 2010-07-09 07:46:57

@JeremyP: That's true, but jbrennan's answer did not explain that adequately at all. This answer seems to suggest that simply nulling out the reference you used to call `release` is sufficient, when in fact it requires setting *every* live reference to nil when the object is released. It might just be an accidental oversimplification, but I think this answer definitely gives the wrong impression.

Chuck 2010-07-10 03:27:13

@bbum: Right, perhaps I left the wrong impression in my answer. My answer really only satisfies the occasion where a local pointer is pointing to a deallocated reference, and doesn't affect other references to the garbaged object.

jbrennan 2010-07-10 05:08:50

Answer 2

+3 A:

There is no "failing gracefully" when you message a deallocated object.

An allocated object is backed by a bit of memory allocated on the heap. It may have many references to that allocation; many pointers that contain the address of said allocation. When the object is deallocated, all those pointers are still pointing to it unless explicitly reset to some other value. And, of course, once de-allocated that bit o' memory can be re-allocated.

That is to say that, no, there is no magic -- no efficient magic anyway [see NSZombie] -- for turning all pointers to a particular object into something that magically eats all messages without error.

In other words, you need to architect your app such that objects that are no longer viable are really no longer viable across all layers of your app.

bbum 2010-07-09 05:52:00

Thanks - I've taken this into account and removed the object from the notification loop before deallocation to avoid the error.

Shaun Budhram 2010-07-10 00:20:53

Answer 3

A:

As bbum says, you can't send messages to deallocated objects. It's simply invalid. There isn't even such a thing as a "deallocated object" — once an object is deallocated, it's just gone. It's not a thing anymore and doesn't exist anywhere. Its old bit pattern might remain, or an unrelated object might be put in its place, or absolute garbage — that's where the crashes come from, not some magical "deallocated object" handler.

The correct thing to do if you don't want an object to be sent notifications anymore is just to unregister it from receiving them.

Chuck 2010-07-09 06:12:37

ansaurus

tags:

views:

answers:

Messages to deallocated instance - failing gracefully

related questions