Objective-C: Is there any way to find out what kind of object resides at a particular memory address?

Question

Coming from Java and Python, I am not so well versed in memory management, but is there any way to find out what kind of object resides at a particular memory address?

I am asking because my application terminated with a cryptic message that reads:

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSDecimalNumber encodedURLParameterString]: unrecognized selector sent to instance 0x164840'

and would like to get some clues as to what is going wrong.

And if that is not possible, some debugging techniques for such error messages would be greatly appreciated.

Thanks in advance!!

EDIT: Follow Up Concern (MOVED HERE)

After some investigation of the framework that I have been using, I came across something that I don't really understand.

If I have a method

- (void) myMethod:(NSString *)string {
    [Object anothermethodWithString:string];
}

and I call

[Object myMethod:@"this is a string"];

Do I need to do something like

NSString *string2 = [[NSString alloc] initWithFormat:@"%@", string];
[Object anothermethodWithString:string2];
[string2 release];

instead of the way I had myMethod before? It seems like the string I passed through the parameter of my method got released somewhere, and doing that solves my problem. I guess I don't really understand what exactly @"string" does in terms of memory. Is it like an auto-released NSString?

Answer 1

In gdb you could type

po <address>

to find out the object's description if it's really an Objective-C object.

But in your case it sounds more like you're sending message to an already deallocated object, which will give wrong result on the object's type. Try to enable NSZombie to show what kind of object it actually is.

Answer 2

well, from the error, the object type at that memory address is NSDecimalNumber. You got an error because you called encodedURLParameterString on a NSDecimalNumber which does not have a method with that name.

Answer 3

This type of error is often caused by a "dangling pointer", the result of keeping a pointer reference to an object after it has been deallocated. If an other object is instantiated in the (now empty) memory space and you subsequently send a message through the dangling pointer, you get an error like that you've observed. This particular error is caused by sending a message encodedURLParameterString to an NSDecimalNumber.

The fact that the beginning of the struct objc_object of an NSDecimalNumber instance is in the memory location previously occupied by the object you think you're referencing isn't of much consequence. You really care about where the dangling reference is held, and why the object was deallocated before you expected. You can enable NSZombie tracking, which keeps deallocated objects alive and stops in the debugger when you try to send them a message. You can also investigate the stack trace from the site of the crash. The previous stack frame will likely point you to where the offending message was sent from, and thence to the reference that was used.

Once you've identified where the dangling reference is being kept, you should check whether that reference is correctly retained (to keep the object alive).