Получение информации о неверном адресе памяти в LLDB

Question

Я пытаюсь отладить EXC_BAD_ACCESS в моем приложении для iPhone.Это сбой при вызове метода и в строке метода EXC_BAD_ACCESS (code=1, address = xxx).

Раньше я бы просто использовал gdb info malloc-history <xxx> для начала отладки, но у меня возникают проблемы с поиском параллельной команды в LLDB.

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

Мне просто нужно выяснить, на что указывает этот сбойный фрагмент памяти.Каков наилучший способ сделать это, используя LLDB или инструменты?

Answer 1

Вы можете увидеть стек malloc при отладке с использованием инструментов.

Я столкнулся с той же проблемой, что и вы, и так же хотел узнать, как получить историю malloc при использовании lldb.К сожалению, я не нашел изящной команды типа malloc-history, найденной в GDB.Честно говоря, я просто переключил свой отладчик, но я обнаружил, что это раздражает, поскольку я чувствовал, что не должен был этого делать.

Чтобы найти историю malloc с помощью инструментов:

1. Профиль вашего проекта
2. Выберите зомби из списка инструментов
3. Заставьте ваше приложение вызвать проблему
4. На этом этапе вам должен быть представлен адрес, который уже былосвободить, и вы можете исследовать это. Это должен быть простой вопрос просмотра истории malloc на этом этапе.Я вычеркнул части, в которых имена классов / проектов были характерны для работы, которую я делаю, но я думаю, что суть и полезность того, как получить эту информацию, присутствуют.

Последнее слово

Проблема, с которой я столкнулся, привела к появлению такого сообщения:

*** - [someClass retain]: сообщение отправлено на освобожденный экземпляр 0x48081fb0 someProject (84051,0xacd902c0) malloc: запись стеков mallocна диск с помощью стандартного рекордерана).Оказывается, я не звонил removeObserver:forKeyPath:, когда определенный объект был dealloc '.Позже во время выполнения KVO произошло do для установщика в строке, что привело к взрыву программы, поскольку KVO пытался уведомить объект, который уже был освобожден.

Answer 2

Эту проблему очень легко решить с помощью информативного обратного следа.К сожалению, с последней версией iOS и Xcode, хороший трек стека иногда бывает трудно найти.К счастью, вы можете установить «точку останова исключения» в XCode, чтобы позволить вам изучить этот код до исключения EXC_BAD_ACCESS.

1. Открыть навигацию по точке останова в XCode 4 (Это выглядит как прямоугольник с точкой направая сторона)
2. Нажмите кнопку «+» в левом нижнем углу и добавьте «Точку останова исключения».Убедитесь, что вы отключили «On Throw» для исключений «All».

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

Answer 3

вы можете использовать такую ​​команду в lldb:

image lookup --address 0xec509b

вы можете найти больше команд в: LLDB TO GDB COMMAND MAP

Answer 4

Возможно, уже слишком поздно, но для получения дополнительной помощи на LLDB:

(lldb) p *(MyClassToPrint*)memory_address

например.

(lldb) p *(HomeViewController*)0x0a2bf700