Цель-C: Есть ли способ узнать, какой объект находится по определенному адресу памяти?

Question

Исходя из Java и Python, я не очень хорошо разбираюсь в управлении памятью, но есть ли способ узнать, какой тип объекта находится по определенному адресу памяти?

Я спрашиваю, потому что мое приложение завершилось загадочным сообщением, которое гласит:

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

и хочет получить некоторые подсказки о том, что идет не так.

И если это невозможно, некоторые методы отладки для таких сообщений об ошибках будут с благодарностью.

Заранее спасибо !!

РЕДАКТИРОВАТЬ: Follow-Up Concern (MOVED ЗДЕСЬ )

После некоторого исследования фреймворка, который я использовал, я обнаружил нечтоЯ не очень понимаю.

Если у меня есть метод

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

и я звоню

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

Нужно ли мне делать что-то вроде

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

вместокак у меня был мой метод раньше?Кажется, что строка, которую я передал через параметр моего метода, была выпущена где-то, и это решает мою проблему.Наверное, я не совсем понимаю, что именно @ "string" делает с точки зрения памяти.Это как автоматически выпущенный NSString?

Answer 1

хорошо, из-за ошибки тип объекта по этому адресу памяти - NSDecimalNumber. Вы получили ошибку, потому что вы вызвали encodedURLParameterString для NSDecimalNumber, у которого нет метода с таким именем.

Answer 2

Этот тип ошибки часто вызывается «висящим указателем», результатом сохранения ссылки указателя на объект после его освобождения.Если другой объект создается в (теперь пустом) пространстве памяти, и вы впоследствии отправляете сообщение через висячий указатель, вы получаете ошибку, подобную той, которую вы наблюдали.Эта конкретная ошибка вызвана отправкой сообщения encodedURLParameterString на NSDecimalNumber.

Тот факт, что начало struct objc_object экземпляра NSDecimalNumber находится в области памяти, ранее занятой объектом, на который вы ссылаетесь, не имеет большого значения.Вы действительно заботитесь о том, где хранится свисающая ссылка, и почему объект был освобожден раньше, чем вы ожидали.Вы можете включить NSZombie отслеживание, которое поддерживает освобождение освобожденных объектов и останавливается в отладчике, когда вы пытаетесь отправить им сообщение.Вы также можете исследовать трассировку стека с места сбоя.Предыдущий кадр стека, скорее всего, укажет вам, откуда было отправлено сообщение о нарушении, и, следовательно, на использованную ссылку.

После того, как вы определили, где хранится свисающая ссылка, вы должны проверить,ссылка сохраняется правильно (для поддержания объекта в живых).

Answer 3

В GDB вы можете набрать

po <address>

чтобы узнать описание объекта , если это действительно объект Objective-C.

Но в вашем случае это больше похоже на то, что вы отправляете сообщение уже освобожденному объекту, что даст неправильный результат в зависимости от типа объекта. Попробуйте включить NSZombie , чтобы показать, что это за объект на самом деле.