(gdb) break *0x972

Debugging, GNU± Linux and WebHosting and ... and ...

C'est quoi le debugging, en fait ?



Une thèse sur le debugging de machin truc, c'est bien, mais si on ne sait pas ce que c'est du debugging, ça n'avance pas beaucoup. Pourtant ce n'est pas uniquement de l'informatique ... Un exemple :

J'ouvre le frigo et la lumière ne s'allume pas. C'est un bug !
Il faut maintenant résoudre ce problème. Quelles peuvent-être les causes ?

  • 1) l'ampoule est grillée
  • 2) l'interrupteur de la porte de s'active pas
  • 3) le frigo n'est pas branché
  • 4) il n'y a pas d'électricité dans la maison
  • -1) une brique de lait cache l'ampoule
  • 0) il y a trop de lumière dans la maison pour distinguer la lumière du frigo

les causes -1 et 0, c'est l'utilisateur qui s'y prend mal, on y peut rien ==> PEBCAK : Problem exists between chair and keyboard, en français problème avec l'interface chaise-clavier :-)

  • pour 1) ce n'est pas facile à tester, suivant !
  • pour 2) on appuie manuellement sur l’interrupteur, est-ce que ça marche ?
  • pour 3) on regarde si la prise est branchée
  • pour 4) on allume une lumière dans la maison

Ça devrait être suffisant pour cerner le problème.
1/ et 2/ ce sont des problèmes mineurs, non prioritaires.
3/ et 4/ sont plus critiques. Est-ce que c'est grave ?

* 5/ est-ce que le frigo/congel sont toujours froid ?

C'est l'application de la méthode scientifique ! On fait des hypothèses qui pourraient expliquer notre observation, des expérimentations pour les tester, et on tire des conclusions de ces résultats.

Le problème du frigo, c'était cet été, en arrivant en vacances ;-)



En informatique, c'est pareil. Enfin ... sauf que les problèmes ne sont pas toujours aussi simple à décrire, les hypothèses pas faciles à formuler, et les expérimentations pas faciles à réaliser !

Déjà, les programmes ont un état interne (les 4Go de RAM de l'ordi principalement, mais aussi les fichiers du disque dur). On n'a pas beaucoup d'exemple de systèmes à état interne dans la vie de tous les jours, c'est dur de trouver un exemple non informatique ...

On peut prendre ... un enfant qui apprend ! On part de zéro, aucune connaissance (faut pas extrapoler l'exemple hein, c'est juste un support !).

  1. Maternel, on apprend la vie en communauté
  2. Élémentairement, on apprend 1/ le français, 2/ les maths
  3. Collège, on apprend l'anglais à la suite du français, en on renforce les maths
  4. ==> How you solve x = 5x² + 3x + 10 for x ? heu ... se sé pas !

Eh oui, ça bug ! Des hypothèses ?

  • parle pas anglais
  • sait pas résoudre d'équation
  • sourd ! (oui, faut penser à tout :-)

Comment on peut tester ça ? on peut voir s'il parle anglais, pour comprendre la question, ... mais si nous, on ne parle pas anglais ? (on peut voir s'il parle français, si non, il ne peut pas avoir appris l'anglais).
Mais et s'il a planté ? si on a seulement sa feuille d'exercice ? Et ben il faut faire une thèse pour construire de nouveaux outils !



Ces outils, ça peut être un voltmètre pour mesurer la tension aux bornes de l'ampoule du frigo. C'est réaliste cet exemple de voltmètre/ampèremètre/ohmmètre , parce que ça ressemble assez à ce que je fais : on se branche sur un circuit, les outils nous permettent d'observer des paramètres "invisibles" à l’œil nu. C'est du debugging interactif.

Ça peut être aussi le dossier de suivi de l'élève, avec des nôtres prises chaque trimestre, on peut savoir comment s'est déroulée son éducation (à condition d'aller à lire ce que les enseignants ont écrits !). C'est moins mon domaine ça, c'est de l'analyse de trace.

On peut aussi valider à l'avance le programme des enseignements qu'il doit obligatoirement suivre pour être sur de réussir notre test (c'est plus facile en informatique qu'en vrai ça ;-).



Et pour expliquer ma thèse, on peut prendre un dernier exemple.

On se place dans un contexte industriel particulier, par exemple, deux équipes de foot (= une application multicœur) qui doivent faire un match.
Les deux équipes, c'est des applications, et les joueurs, des processeurs.

Dans l'état actuelle de la science, on peut regarder une personne*, suivre ses déplacements, écouter ce qu'elle dit.
On peut aussi regarder plusieurs personnes d'une équipe, mais on regardera chaque personne indépendamment, sans notion d'équipe ou de collaboration.

Essaies de comprendre un match en ne regardant qu'un joueur à la fois ! S'il a le ballon, oui c'est bien, mais il fait une passe. Il faut que tu passes tous les autres joueurs en revu pour voir s'ils on le ballon.
Essaies de comprendre pourquoi Machin a fait la passe à Untel, si tu ne connais pas la tactique de jeu, ni la position du ballon ...

Ma contribution, c'est de montrer qu'on peut faire des outils (et qu'ils sont utiles !) qui vont connaitre les règles du jeu (du foot, du rugby, du hand). Au lieu de montrer des bonshommes qui bougent dans tous les sens sur une pelouse, l'outil montrera des joueurs, avec des numéros, des rôles, des tactiques de jeu, et un ballon. Au lieu de voir une personne qui courre bizarrement et tombe, puis une autre qui se met à faire, on verra un footballer qui drible, se fait tacler et prendre le ballon. Au lieu d’écouter une personne parler toute seule (50% du dialogue), on verra qu'elle échange avec un autre joueur et qu'ils se mettent d'accord sur la prochaine action.

C'est du model-centric debugging for multicore embedded systems !

* une fois, mais est-ce qu'on ne peut déboguer 1000 fois 1000 personnes ?