Disons que logcat vous montrer la suite de crash (c'est de l'un de mes projets):
I/DEBUG ( 31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 31): Build fingerprint: 'generic/sdk/generic:2.3/GRH55/79397:eng/test-keys'
I/DEBUG ( 31): pid: 378, tid: 386 >>> com.example.gltest <<<
I/DEBUG ( 31): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG ( 31): r0 001dbdc0 r1 00000001 r2 00000000 r3 00000000
I/DEBUG ( 31): r4 00000000 r5 40a40000 r6 4051a480 r7 42ddbee8
I/DEBUG ( 31): r8 43661b24 r9 42ddbed0 10 42ddbebc fp 41e462d8
I/DEBUG ( 31): ip 00000001 sp 436619d0 lr 83a12f5d pc 8383deb4 cpsr 20000010
I/DEBUG ( 31): #00 pc 0003deb4 /data/data/com.example.gltest/lib/libnativemaprender.so
I/DEBUG ( 31): #01 pc 00039b76 /data/data/com.example.gltest/lib/libnativemaprender.so
I/DEBUG ( 31): #02 pc 00017d34 /system/lib/libdvm.so
Regardez les 3 dernières lignes; c'est votre pile des appels. " pc " est le compteur de programme, et le pc pour la trame de pile #00 vous donne l'adresse où le crash s'est produit. C'est le nombre de passer de addr2line.
Je suis l'aide de NDK r5, de sorte que l'exécutable que j'utilise est situé à l' $NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
; assurez-vous que c'est dans votre $PATH
. La commande à utiliser ressemble
arm-linux-androideabi-addr2line -C -f -e obj/local/armeabi/libXXX.so <address>
Ou, pour le cas ci-dessus:
arm-linux-androideabi-addr2line -C -f -e obj/local/armeabi/libnativemaprender.so 0003deb4
Qui vous donne l'emplacement de l'accident.
Note:
- L'indicateur-C est-à-demangle code C++
- Utiliser le .si le fichier de sous
obj/local/armeabi, puisque c'est la
non dépouillé version
Aussi, lors de l'utilisation de NDK r5 avec un 2.3 AVD, il est effectivement possible de déboguer du code multithread.