Как отлаживать аварию на основе аварии?

Я получил следующий след на Android.Как отлаживать аварию на основе аварии?

Вопрос 1: Что смысл r0 ... r9 и сл, Ф.П., ф, зр, Л.Р., сл, ПК, cpsr. Я пытаюсь отладить acrroding до информации fault addr 0xb0.

фрагмент кода, как это:

memcpy(mAudioFrameBuffers[write_pos]->data, audioFrame->data, audioFrame->frameSize);

Трассировка:

12-13 13:33:19.182 I/DEBUG (19867): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
12-13 13:33:19.183 I/DEBUG (19867): Build fingerprint: 'motorola/shamu_retcn/shamu_t:5.0.2/LXG22.67-7.1/2:user/release-keys' 
12-13 13:33:19.183 I/DEBUG (19867): Revision: 'p2b0' 
12-13 13:33:19.183 I/DEBUG (19867): ABI: 'arm' 
12-13 13:33:19.183 I/DEBUG (19867): pid: 22064, tid: 22137, name: AsyncTask #1 >>> com.jerikc.mediastreamerdemo <<< 
12-13 13:33:19.183 I/DEBUG (19867): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb0 
12-13 13:33:19.205 I/DEBUG (19867):  r0 00000003 r1 a2dc2bb0 r2 00125365 r3 000000b0 
12-13 13:33:19.205 I/DEBUG (19867):  r4 a3507160 r5 a35090e8 r6 a2dc6ddc r7 a2dc2bb0 
12-13 13:33:19.205 I/DEBUG (19867):  r8 a2dc6ef4 r9 a2dc3ce6 sl d00bff18 fp 148fb9e5 
12-13 13:33:19.205 I/DEBUG (19867):  ip a1303810 sp a1303cd8 lr a2c9d96b pc a2c9d97a cpsr 200f0030 
12-13 13:33:19.205 I/DEBUG (19867): 
12-13 13:33:19.205 I/DEBUG (19867): backtrace: 
12-13 13:33:19.205 I/DEBUG (19867):  #00 pc 0001897a /data/app/com.jerikc.mediastreamerdemo-2/lib/arm/libMediaStreamer.so (AudioFrameBufferPool::push(AudioFrame*)+205) 
12-13 13:33:19.205 I/DEBUG (19867):  #01 pc 0001f5fb /data/app/com.jerikc.mediastreamerdemo-2/lib/arm/libMediaStreamer.so (AudioStreamer::mixThread()+330) 
12-13 13:33:19.205 I/DEBUG (19867):  #02 pc 0001f777 /data/app/com.jerikc.mediastreamerdemo-2/lib/arm/libMediaStreamer.so 
12-13 13:33:19.205 I/DEBUG (19867):  #03 pc 0001666b /system/lib/libc.so (__pthread_start(void*)+30) 
12-13 13:33:19.205 I/DEBUG (19867):  #04 pc 00014643 /system/lib/libc.so (__start_thread+6)

Вопрос 2: Есть ли эффективный метод отладки?

источник

2016-12-13 Jerikc XIONG

r0 to r9 а также sl, fp и т. Д. Являются вашими регистрами. Он просто показывает вам значения регистров, когда код «segfaulted».

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

Что касается отладки, вот что вы может попробовать:

первую очередь, убедитесь, что буферы выделены правильно
компилировать с отладочной информацией/отключение оптимизаций и его падение снова. Вы должны быть в состоянии видеть то, что линия причиной аварии, а также значения переменных (в частности, audioFrame-> FrameSize и mAudioFrameBuffers)

источник

2016-12-22 16:15:55 JLL

Есть здравый смысл, как: значение r0 является '' write_pos, r1 является «mAudioFrameBuffers [write_pos]', r2 является «mAudioFrameBuffers [write_pos] -> data' и т. д.? –

Иногда да, иногда нет, в зависимости от контекста и соответствующих регистров. Например, SP всегда является указателем стека и указывает на часть памяти, которая в настоящее время используется текущей функцией (локальные переменные, параметры и т. Д.). LR является регистром связи и содержит адрес возврата при завершении текущей функции. – JLL

Для r0-r9 это будет зависеть от окружающего кода и не зная, что произошло раньше (например, глядя на код сборки), было бы трудно догадаться, что это за значения. Если вы хотите попытаться угадать, вы должны больше узнать о ARM ABI. Компиляторы будут следовать за ABI, который имеет «рекомендации» относительно того, какую цель дать регистры. – JLL

Как отлаживать аварию на основе аварии?

ответ

Смежные вопросы