Как читать трассировки стека объектов-c

У меня есть следующая трассировка стека:

0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26 1 MyApp 0x000836bd TFSignalHandler + 28 2 libsystem_c.dylib 0x33eac727 _sigtramp + 34 3 ??? 0x00000002 0x0 + 2 4 MyApp 0x000803f1 msgpack_unpack_next + 112 5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74 6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26 7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146 ... 

И мне интересно, как это прочитать:

  • Я предполагаю, что я иду снизу вверх, например, строка 7, называемая строкой 6, называемая строкой 5 и т. Д.
  • Что означает «+ 112» в строке 4? Это номер строки в файле кода, где он разбился?
  • Что это ‘???’ в строке 3 означает?

большое спасибо

 0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26 

Сбой +[TFCrashHandler backtrace] из +[TFCrashHandler backtrace] + 26; от любой команды, упавшей в этом месте символа + 26 байт.

Если это действительно нижняя часть вашей трассировки стека и она разбилась там, то TCrashHandler реальный сбой. Настоящая авария выглядит как пара кадров выше.

 1 MyApp 0x000836bd TFSignalHandler + 28 

TFSignalHandler – это то, что называется + backtrace.

 2 libsystem_c.dylib 0x33eac727 _sigtramp + 34 

Ewww … сигнальный батут. Приложение получило сигнал, и батут был назначен для вызова TFSignalHandler ().

Бывают ситуации, когда обработчик сигналов может быть вызван на случайный stream. Т.е. существует незначительная вероятность того, что эта конкретная авария не имеет ничего общего с парсером и все, что связано с крушением в другом месте. Однако, не зная больше о синтаксическом анализаторе, я бы поставил вопрос о том, затвердевает ли он от вредоносного ввода (что может привести к сбою в этом случае).

 3 ??? 0x00000002 0x0 + 2 

Стек был не поддаётся проверке. Отбой. Бессмысленно. Лучший случай; выпад из оптимизации компилятора. Худший случай; кто-то извергался в стеке, и механизм backtrace не может понять, что происходит (очень маловероятно – обычно, стекольная пупка брызгает до такой степени, что предотвращает полную обратную трассировку).

 4 MyApp 0x000803f1 msgpack_unpack_next + 112 

Ооооо … хитрый. Кто-то использует C для parsingа материала. И он разбился. Какая бы ни была инструкция, 112 байт от точки входа в функцию запустили стрелу . Но на самом деле это не так, потому что он назывался обработчиком сигналов и был обработан этим; который по-прежнему бум, но обработчик сигналов эффективно уничтожил дополнительные судебные доказательства.

В «хитрых» комментариях упоминается, что оптимизирующий компилятор против большой кучи o C может закончиться свертыванием кадров до такой степени, что авария могла произойти в функции, значительно ниже этой.

 5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74 

MessagePackParser разбирался, когда дела шли ужасно неправильно.

 6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26 7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146 

Ahh … да … кто-то сделал, захватил некоторые данные из HTTP, и он был искажен, что вызвало крах.

Нижняя линия; парсер получил фиктивный вход и разбился. Был обработчик сигнала, который пытался помочь, создав обратную линию, но, по-видимому, на самом деле не раскрыл больше информации. Альтернатива длинным выстрелом заключается в том, что сигнал генерировался где-то в другом месте, и этот stream был случайным образом выбран для его обработки – если вы можете последовательно воссоздать этот сбой, случай случайного streamа-сигнала маловероятен.

Если у вас нет захвата входных данных или вы можете каким-то образом догадаться, как может произойти сбой msgpack_unpack_next (), вам не повезло, не предоставив больше информации.

«???» это то, что невозможно идентифицировать, вероятно, код, который был скомпилирован без символов, но может также быть чем-то другим.

Это номера строк в файле реализации. И hex – это указатель в памяти на вызов линии.

Interesting Posts
Давайте будем гением компьютера.