Chercher la petite bête

Dans la littérature, on trouve une taxinomie des bugs teintée d’humour, mais non dépourvue d’une certaine réalité.

Taxinomie¶

L’Heisenbug (en hommage au physicien Werner Heisenberg). Bug qui, par analogie au principe d’incertitude d’Heisenberg, n’est pas possible d’observer (ou instrumenter) sans dégrader ou modifier le comportement de l’application. Un grand classique est de mettre une trace pour comprendre et de ne plus observer de problème. Dans les causes principales, on retrouve :

• Un problème de synchronisme (ou d’asynchronisme) : la mise en œuvre de profils d’exécutions restreints tels que Ravenscar (Ada${2005}*) ou Jorvik (Ada$$) permettent de limiter ces causes.

• Une variable non initialisée : hormis les avertissements du compilateur, dans le cadre de la technologie GNAT, la mise en œuvre du pragma Initialize_Scalars et de l’option --gnatVa permettent de corriger au plus tôt cette cause.

• Une référence fantôme sur la pile : par construction, le langage Ada ne le permet pas sauf choix explicite (Unchecked).

Le Schrödinbug (en hommage au physicien Erwin Schrödinger et à son fameux chat). Bug dont on ne connait pas l’existence. Pour le détecter, il faut par exemple lire le code. Par analogie, on ne peut pas savoir si le chat est vivant ou mort avant d’avoir ouvert la boite !

Le Mandelbug (en hommage au mathématicien Benoit Mandelbrot). Bug dont les causes sont suffisamment complexes pour le rendre apparemment non déterministe. Ce type de bug est difficile à corriger.

Le Bohrbug (en hommage au physicien Niels Bohr) qui est l’opposé de l’Heisenbug : c’est un « simple » bug, mais pas nécessairement un bug simple…

Méthode¶

Dans son « Discours de la méthode », Descartes propose quatre principes :

• « Ne recevoir aucune chose pour vraie que je ne la connusse évidemment être telle ».

• « Diviser chacune des difficultés que j’examinerais, en autant de parcelles qu’il se pourrait et qu’il serait requis pour les mieux résoudre ».

• « Conduire par ordre mes pensées, en commençant par les objets les plus simples et les plus aisés à connaître pour monter peu à peu, comme par degrés, jusqu’à la connaissance des plus composés ».

• « Faire partout des dénombrements si entiers, et des revues si générales, que je fusse assuré de ne rien omettre ».

Aussi surprenant que cela puisse paraitre, ces principes de bon sens sont pertinents pour « chercher la petite bête ». Cependant, nous allons les reformuler pour notre propos :

• Pour le premier, cela veut dire qu’il ne faut prendre en compte dans son analyse du problème que les faits dont on est certain.

• Pour le second, cela veut dire qu’il faut découper un gros problème en plus petits problèmes plus simples à adresser.

• Pour le troisième, cela veut dire qu’il faut commencer les investigations sur ce qu’il y a de plus simple et si cela s’avère nécessaire commencer à descendre dans les parties plus profondes du code. Par exemple, si j’ai un « problème de socket » je ne vais pas commencer à mettre en doute la pile IP.

• Pour le quatrième, cela veut dire qu’il faut vous assurer que vous avez bien tout le contexte lors de l’occurrence d’un bug (versions des sources, options mises en œuvres, droits, niveau de mise à jour des cibles, etc.). Cela est particulièrement vrai pour le Mandelbug car il peut alors se ramener à un Bohrbug si vous arrivez à recréer le bon contexte.