Outils pour utilisateurs

Outils du site


openbsd.org:ddb

[ OpenBSD ] ~ Traduction française de la page OpenBSD: Crash Reports : (v1.23 ; 13/3/2021)

OpenBSD : Rapports de Crash

Informations minimum pour les problèmes de noyau

Premièrement, familiarisez vous avec les procédures de rapport de bogues. Toutes celles-ci s'appliquent. Lors d'un rapport d'un crash ou panic du noyau, veuillez vous rappeler que :

  • Nous avons besoin de la sortie console de l'écran. Capturez-la et sauvegardez-la. Les consoles séries sont meilleures, mais si avez une console VGA, vous pouvez faire défiler la console en arrière et prendre une photo lisible avec un téléphone ou appareil photo.
  • Si le noyau a paniqué, nous avons besoin du message de panic et du traceback. Il peut être affiché à l'écran. Si vous êtes à l'invite ddb>, tapez show panic puis trace. Si vous utilisez un système SMP, utilisez la commande mach ddbcpu Npour chacun des processeurs que vous avez et répétez la commande trace sur chaque processeur.
  • Nous avons besoin de la liste des processus. Utilisez la commande ps pour l'obtenir.

Les rapports sans les informations ci-dessus sont inutiles. C'est le minimum dont nous avons besoin afin d'être capable de cerner le problème.

Informations additionnelles que vous pouvez envoyer

Dans certaines situations, avoir plus d'informations est désirable. Ci-dessous sont soulignées les étapes additionnelles que vous pouvez prendre dans ces situations :

  • Si votre crash semble impliquer des systèmes de fichiers. Les choses suivantes peuvent être bien utiles :
    • la sortie de la commande ddb> show uvm.
    • la sortie de la commande ddb> show bcstats.
    • la sortie de la commande mount sur votre machine fonctionnelle, ainsi nous connaîtrons quels systèmes de fichiers sont montés et comment.
  • … XXX crash au démarrage ? XXX
  • … XXX montre les regs ? XXX

Perte du message panic ?

Sous certaines circonstances, vous pouvez perdre le premier message de panique, donnant la raison de celle-ci.

ddb> show panic
0:      kernel: page fault trap, code=0
ddb>

Note pour les systèmes SMP

Vous devriez avoir une trace de chacun des processeurs en tant que partie de votre rapport :

ddb{0}> trace
pool_get(d05e7c20,0,dab19ef8,d0169414,80) at pool_get+0x226
fxp_add_rfabuf(d0a62000,d3c12b00,dab19f10,dab19f10) at fxp_add_rfabuf+0xa5
fxp_intr(d0a62000) at fxp_intr+0x1e7
Xintr_ioapic0() at Xintr_ioapic0+0x6d
--- interrupt ---
idle_loop+0x21:
ddb{0}> machine ddbcpu 1
Stopped at      Debugger+0x4:   leave
ddb{1}> trace
Debugger(d0319e28,d05ff5a0,dab1bee8,d031cc6e,d0a61800) at Debugger+0x4
i386_ipi_db(d0a61800,d05ff5a0,dab1bef8,d01eb997) at i386_ipi_db+0xb
i386_ipi_handler(b0,d05f0058,dab10010,d01d0010,dab10010) at i386_ipi_handler+0x
4a
Xintripi() at Xintripi+0x47
--- interrupt ---
i386_softintlock(0,58,dab10010,dab10010,d01e0010) at i386_softintlock+0x37
Xintrltimer() at Xintrltimer+0x47
--- interrupt ---
idle_loop+0x21:
ddb{1}>

Répétez la commande machine ddbcpu x suivie par trace pour chaque processeur dans votre machine.

Comment puis-je recueillir des informations supplémentaires à partir d'un crash du noyau ?

Un crash typique de noyau peut ressembler à ceci :

kernel: page fault trap, code=0
Stopped at    pf_route+0x263:        mov     0x40(%edi),%edx
ddb>

Ce crash arrive à l'offset 0x263 dans la fonction pf_route.

La première commande à exécuter à l'invite ddb(4) est trace :

ddb> trace
pf_route(e28cb7e4,e28bc978,2,1fad,d0b8b120) at pf_route+0x263
pf_test(2,1f4ad,e28cb7e4,b4c1) at pf_test+0x706
pf_route(e28cbb00,e28bc978,2,d0a65440,d0b8b120) at pf_route+0x207
pf_test(2,d0a65440,e28cbb00,d023c282) at pf_test+0x706
ip_output(d0b6a200,0,0,0,0) at ip_output+0xb67
icmp_send(d0b6a200,0,1,a012) at icmp_send+0x57
icmp_reflect(d0b6a200,0,1,0,3) at icmp_reflect+0x26b
icmp_input(d0b6a200,14,0,0,d0b6a200) at icmp_input+0x42c
ipv4_input(d0b6a200,e289f140,d0a489e0,e289f140) at ipv4_input+0x6eb
ipintr(10,10,e289f140,e289f140,e28cbd38) at ipintr+0x8d
Bad frame pointer: 0xe28cbcac
ddb>

Cela nous dit quels appels de fonction mènent au crash.

Pour trouver quelle ligne de code C en particulier a causé le crash, vous pouvez faire ce qui suit :

Trouvez le fichier source où la fonction qui crash est définie. Dans cet exemple, ce serait pf_route() dans le fichier /sys/net/pf.c. Utilisez objdump(1) pour obtenir le désassemblage :

$ cd /sys/arch/$(uname -m)/compile/GENERIC
$ objdump -dlr obj/pf.o >/tmp/pf.dis

Dans la sortie, utilisez grep pour rechercher où est le nom de la fonction :

$ grep "<pf_route>:" /tmp/pf.dis
00007d88 <pf_route>:

Prenez le premier nombre hexadécimal 7d88 et ajoutez l'offset 0x263 depuis la ligne Stopped at :

$ printf '%x\n' $((0x7d88 + 0x263))
7feb

Défilez jusqu'à la ligne 7feb. L'instruction d'assembleur doit correspondre à celle indiquée à la ligne Stopped at. Ensuite, faites défiler jusqu'au numéro de la ligne de code C le plus proche.

$ more /tmp/pf.dis
/sys/net/pf.c:3872
    7fe7:       0f b7 43 02             movzwl 0x2(%ebx),%eax
    7feb:       8b 57 40                mov    0x40(%edi),%edx
    7fee:       39 d0                   cmp    %edx,%eax
    7ff0:       0f 87 92 00 00 00       ja     8088 <pf_route+0x300>

Ainsi, c'est précisément la ligne 3872 du fichier pf.c qui crash :

$ nl -ba /sys/net/pf.c | sed -n 3872p
  3872		if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {

Le noyau qui a produit la sortie du crash et le fichier objet pour objdump doit être compilé depuis exactement les mêmes fichiers sources, autrement les offsets ne correspondront pas.

Si vous fournissez les deux, la sortie trace de ddb et la section pertinente d'objdump, cela sera vraiment très utile.


Cette page est la traduction officieuse de la page « Crash Reports » officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.


Contribut(rice|eur)s :

pengouinpdt
openbsd.org/ddb.txt · Dernière modification: 2021/05/02 18:35 de pengouinpdt