Que mettre dans un rapport de problème

• Conseils
• Quand rapporter une panique noyau

Une base de données n'est bonne qu'en fonction des données qu'elle contient. Généralement, le sens commun (si quelque animal peut l'avoir) dicte le type d'informations les plus utiles pour traquer et résoudre un problème logiciel.

Conseils

• Précisez toutes les informations que vous auriez aimé trouver si vous deviez recevoir ce rapport. Inutile d'inclure les moindes détails de votre environnement mais tout ce qui peut être différent chez quelqu'un d'autre est utile (votre chemin d'accès, par exemple).

• Les récits sont souvent utiles mais dans certaines limites. Si la personne responsable d'un bug peut voir que A a été exécuté puis B et C, elle peut alors trouver qu'il manque une étape intermédiaire ou qu'une étape supplémentaire a suffisamment changé l'environnement pour que le problème apparaisse. Encore une fois, maitrisez l'ordre («j'ai lancé la compilation, suis allé prendre un café (colombien, nuage de lait mais sans sucre), ai parlé à Sheila au téléphone et C'EST arrivé...») mais soyez sûr que toutes les informations pertinentes sont incluses.

• Richard Stallman a écrit,

  Le principe fondamental pour utilement signaler un bug est le suivant : rapportez tous les faits. Si vous ne savez pas si vous devez signaler un fait ou pas, signalez-le !

  Cela vaut pour tout type de problèmes. Pour les logiciels comme pour les injustices sociales ou la réparation d'une moto. C'est spécialement important en informatique car un tout petit changement peut avoir de grosses conséquences (une variable modifiée, deux points manquants...)

• Ne signalez qu'un seul problème à la fois. Si vous en avez plusieurs, utilisez un PR (Problem Report) pour chacun. Cela aide à traquer chaque problème et à analyser les problèmes en fonction d'un programme donné.

• Cela ne fait jamais de mal de chercher si le problème n'a pas déjà été rapporté. La plupart des logiciels sont accompagnés d'une liste des bugs connus. De plus, il est toujours préférable de consulter la base de données des rapports de problèmes GNATS de NetBSD pour voir si quelqu'un n'a pas déjà eu le problème (qui sait ? Si ça se trouve il y a même une correction ou un contournement).

• Plus le rapport est proche du format standard, moins l'administrateur de la base aura de mal à le placer au bon endroit. Souvenez-vous que tout ce qui demande une action humaine demande du temps qui peut aussi être utilisé pour corriger le problème. Il est donc dans l'interrêt de tous que les informations du rapport soient le plus correctes possibles (dans la forme et le fond) au moment de l'envoi. Reportez-vous à la description des champs dans un rapport de problèmes, pour plus de détails.

Quand rapporter une panique noyau

Donc le noyau a paniqué et vous a affiché une bonne quantité de nombres hexadécimaux avant de s'arrêter. Il est important pour vous de signaler cet évènement car un vrai système d'exploitation ne plante ou ne panique jamais si le matériel n'est pas en cause (rares sont les logiciels qui puissent faire quelque chose contre des pannes matérielles). Le bug est alors la seule explication. Nous devons donc le traquer et l'écraser pour que NetBSD soit toujours plus stable et plus robuste que jamais.

Le problème est que l'état de la pile que le noyau a affiché est spécifique à votre noyau. Les nombres doivent donc être re-convertis en symboles de la table de référence pour qu'une personne ne possédant pas votre noyau puisse se faire une image précise de l'endroit où il a décidé de s'arrêter.

Au minimum, recopiez les nombres du «PC» et convertissez-les en référence symboliques (il s'agit du Program Counter de votre ordinateur, l'endroit où en est le programme). Le mieux serait même que vous vous arrangiez pour copier et coller tout le texte.

Donc, si le noyau vous affiche quelque chose comme (généralement sur plusieurs lignes) :

pc = 0xf80ff430 args = (0x0, 0x41001fe5, 0xf8139c00, 0xf8123d20, 0xf8101e38, 0xf8143800, 0xf8123c68) fp = 0xf8123c68

Le numéro du PC est spécifique au noyau que vous utilisez et est probablement différent de celui des autres personnes. Il doit donc être converti en référence à un symbole. Pour convertir un nombre hexadécimal en référence à un symbole, utilisez gdb(1), de la façon suivante :

	gdb -k /netbsd
	x 0xf80ff430

	0xf80ff430 <cpu_reboot+196>:     0x40000093

Le résultat <cpureboot+196> issu de gdb(1) est ce dont ont besoin les gens qui seront amenés à travailler sur le problème. Mettez-le dans le rapport, accompagné des autres arguments de cette ligne.

A la page rapport de problème #3765, vous trouverez un exemple exhaustif de rapport sur une panique noyau.

Accueil