Como ler traços de pilha do object-c

Eu tenho o seguinte rastreamento de pilha:

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 ... 

E eu estou querendo saber como lê-lo:

  • Eu suponho que eu vá de baixo para cima, por exemplo, linha 7 chamada linha 6 chamada linha 5, etc.
  • O que significa ‘+ 112’ na linha 4? Isso é um número de linha no arquivo de código onde ele caiu?
  • O que faz o ‘???’ na linha 3 significa?

Muito obrigado

 0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26 

Crash foi gerado a partir de +[TFCrashHandler backtrace] + 26; de qualquer instrução caiu naquele local de símbolo + 26 bytes.

Se essa for realmente a parte inferior do seu rastreio de pilha e ela cair lá, então o TCrashHandler está ocultando a falha real. O acidente real parece ser um par de frameworks acima.

 1 MyApp 0x000836bd TFSignalHandler + 28 

TFSignalHandler era o que chamava de + backtrace.

 2 libsystem_c.dylib 0x33eac727 _sigtramp + 34 

Eca … um trampolim de sinal. O aplicativo recebeu um sinal e o trampolim foi definido para chamar TFSignalHandler ().

Existem situações em que um manipulador de sinal pode ser chamado em um encadeamento random. Ou seja, há uma chance minúscula de que esse acidente em particular não tenha nada a ver com o analisador e tudo a ver com uma falha em outro lugar. No entanto, sem saber mais sobre o analisador, eu questionaria se ele é protegido contra inputs maliciosas (o que certamente poderia causar uma falha como essa).

 3 ??? 0x00000002 0x0 + 2 

Stack era indeciso. Ignorar. Sem significado. Melhor caso; precipitação da otimização do compilador. Pior caso; alguém pooped na pilha e o mecanismo de backtrace não pode descobrir o que está acontecendo (altamente improvável – geralmente, empilhe splatters de cocô ao ponto de impedir um backtrace completo).

 4 MyApp 0x000803f1 msgpack_unpack_next + 112 

Ooooh … trickzy. Alguém está usando C para analisar as coisas. E isso caiu. Seja qual for instrução foi de 112 bytes a partir do ponto de input para a function foi boom . Mas, na verdade, não, porque chamava o manipulador de sinal e era tratado por isso; que ainda é um boom, mas o manipulador de sinais efetivamente destruiu provas forenses adicionais.

O comentário “trickzy” faz referência a um compilador otimizador contra uma pilha grande de C que pode acabar colapsando frameworks até o ponto em que a falha poderia ter acontecido em uma function bem abaixo dessa.

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

MessagePackParser estava analisando quando as coisas davam terrivelmente errado.

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

Ahh … sim …. alguém pegou alguns dados do HTTP e foi malformado, causando o travamento.

Linha de fundo; o analisador recebeu uma input falsa e caiu. Havia um manipulador de sinal que tentava ajudar criando um backtrace, mas – aparentemente – não revelava mais nenhuma informação. Uma alternativa a longo prazo é que o sinal foi gerado em algum outro lugar e este thread foi selecionado aleatoriamente para lidar com ele – se você puder recriar consistentemente esse travamento, o caso de sinal de thread random é improvável.

A menos que você tenha uma captura dos dados de input ou possa de alguma forma adivinhar como o msgpack_unpack_next () pode falhar, você está sem sorte sem fornecer mais informações.

O ‘???’ é algo que não pode ser identificado, provavelmente código que foi compilado sem símbolos, mas também pode ser outra coisa.

Esses são os números de linha no arquivo de implementação. E o hex é o ponteiro na memory para a chamada de linha.