0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
Сбой был получен из +[TFCrashHandler backtrace] + 26;из любой инструкции, расположенной в этом месте символа + 26 байт.
Если это действительно нижняя часть трассы стека, и она там потерпела крах, то TCrashHandler скрывает реальный сбой.Настоящий сбой выглядит на пару кадров выше.
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler был тем, что называется + backtrace.
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww ... сигнальный батут.Приложение получило сигнал, и батут был настроен для вызова TFSignalHandler ().
В некоторых ситуациях обработчик сигнала может быть вызван в произвольном потоке.Т.е. есть небольшая вероятность того, что этот конкретный сбой не имеет ничего общего с синтаксическим анализатором и не имеет ничего общего с каким-либо другим событием.Однако, не зная больше о синтаксическом анализаторе, я бы усомнился, защищен ли он от вредоносного ввода (который, безусловно, может привести к сбою, подобному этому).
3 ??? 0x00000002 0x0 + 2
Стек был не декодируемым.Отбой.Бессмысленно.Лучший случай;последствия от оптимизации компилятора.Худший случай;кто-то обрушился на стек, и механизм обратного отслеживания не может выяснить, что происходит (очень маловероятно - обычно разбрызгивание стека до точки предотвращения полного обратного отслеживания).
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Оооооо ..хитрыйКто-то использует C для разбора вещей.И это разбилось.Независимо от того, какая инструкция составляла 112 байтов от точки входа в функцию, получалось boom .Но не совсем, потому что он вызывал обработчик сигнала и был обработан этим;который по-прежнему бум , но обработчик сигнала фактически уничтожил дополнительные криминалистические доказательства.
В «хитром» комментарии упоминается, что оптимизирующий компилятор против большой кучи 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
Ааа ... да ... кто-то уже получил некоторые данные из HTTP, и они были искажены, что привело к сбою.
Итог;парсер получил фальшивый ввод и вылетелБыл обработчик сигнала, который пытался помочь, создавая обратную трассировку, но - по-видимому - больше не раскрывал никакой информации.Долгосрочная альтернатива состоит в том, что сигнал был сгенерирован где-то еще, и этот поток был случайно выбран для его обработки - если вы можете последовательно воссоздать этот сбой, случайный поток сигнала маловероятен.
Если у вас нетзахват входных данных или каким-то образом угадать, как msgpack_unpack_next () может произойти сбой, вам не повезло, не предоставив дополнительную информацию.