Bug logiciel inhabituel

En programmation informatique, un bug logiciel inhabituel est un bug considéré comme très difficile à détecter et à réparer. Il en existe plusieurs types souvent désigné d'après le nom de scientifiques qui ont découvert des principes non intuitifs.

Schrödinbug

Un schrödinbug^[1] (ou schroedingbug) est un bug qui n'est pas découvert et non gênant pour les utilisateurs, mais qui apparaît après que quelqu'un a relu le code source ou utilise le logiciel d'une façon non habituelle. À partir de ce moment-là, le programme ne fonctionne plus pour personne, jusqu'à ce que le bug soit corrigé.

Le fait que le bug se manifeste juste après que quelqu'un a relu le code source est impossible. Le phénomène se produit lorsque l'informaticien découvre le bug en lisant le code et le vérifie par un test. Le fait de faire exécuter ce test au programme le met dans un état l'empêchant de fonctionner correctement, ce qui donne l'impression que le bug est apparu alors que le programme n'a pas été modifié. C'est en fait parce que le bug correspond à un rare cas d'utilisation qui n'avait jamais eu lieu auparavant.

Un autre cas de schrödinbug peut se produire lorsque le programme de débogage comporte lui-même un léger bug, et, lorsqu'il est utilisé pour tester un programme, donne le résultat qu'un bug est présent dans le programme testé, alors qu'en mode de fonctionnement effectif, ce bug n'existe pas. À l'inverse, il arrive qu'un bug, détecté lors d'un traitement effectif, n'apparaisse plus lorsqu'il est testé au moyen d'un programme de débogage.

Étymologie

Le mot schrödinbug est la fusion de « Schrödinger », nom du physicien, inventeur du concept du Chat de Schrödinger, et de « bug ».

Heisenbug

Un Heisenbug^[2] est un bug difficile à localiser^[3] parce qu'il ne se manifeste pas^[4] lorsque des outils de détection sont utilisés pour le rechercher.

En pratique, on retrouve l'un des trois cas suivants :

• le programme tourne sous le débogueur, mais pas sur la ligne de commande
• le programme fonctionne compilé en mode normal, mais pas lors d'une compilation avec optimisation
• le programme marche quand on rajoute des printf() pour déboguer, mais pas quand on les enlève

Une cause courante est la présence d'une situation de compétition^[5], un ralentissement de tout ou partie de l'exécution pouvant conduire à déséquilibrer la compétition, qui est alors masquée, et le problème avec.

Un Heisenbug peut aussi apparaître si le principe de séparation requête-action n'est pas respectée, une routine appelée plusieurs fois peut alors retourner des valeurs différentes, créant alors une situation de compétition pouvant être difficile a reproduire.

Une autre source est l'oubli d'initialisation de variables locales^[6]. En mode débogage, les valeurs seront par exemple placées sur la pile, alors qu'en mode optimisé, elles seront placées directement dans les registres du processeur. Une variable qui est utilisée avant d'être assignée aura alors un état indéfini, mais différent dans les deux cas. Les effets peuvent être indirects, par exemple un indice de tableau incorrectement initialisé (mais correct en termes d'étendue, par exemple un zéro), pourra entraîner une écriture dans une mauvaise cellule, ce qui déclenchera le bug plus tard au cours de l'exécution.

Dans les langages à gestion de mémoire manuelle, un Heisenbug peut provenir d'une gestion de la mémoire incorrecte, propice aux fuites de mémoires et à l'écrasement éventuel de données. Les données écrasées seront alors "circonstancielles". Il s'agit d'une cause commune dans les langages tels que C++.

Exemple

En Visual C++, il existe un mode debug (pour la mise au point d'un programme) et un mode release (la version de production généralement). Le mode debug a la "bonne" idée de réserver plus de mémoire qu'il n'en faut réellement. Ce comportement implique que le programme en mode debug plantera rarement, alors qu'en mode release, le programme plantera systématiquement à cause d'un débordement de pile. Il s'agit d'un Heisenbug car lorsqu'on veut l'analyser, il faut passer en mode debug, ce qui le fait disparaître…

Étymologie

Le nom Heisenbug est inspiré du principe d'incertitude d'Heisenberg, défini en physique quantique, qui constate qu'observer une structure modifie son état.

Bohr bug

Un Bohr bug^[7] est un bug qui, à la différence des heisenbugs, ne disparaît ni n'a ses caractéristiques modifiées^[8] lorsqu'il est recherché.

Étymologie

Un Bohr bug est persistant et appelé du nom du modèle atomique de Niels Bohr.

Mandelbug

Un mandelbug^[9] est un bug dont les causes sont si complexes que son comportement apparaît chaotique^[10]; il le reste tant que le testeur n'arrive pas à établir précisément un comportement déterministe d'apparition du bogue^[11]. L'emploi de ce terme signifie également qu'il est plus probablement un Bohr bug qu'un heisenbug.

On peut avancer, d'après le même principe que celui du test de Turing, que s'il n'y a aucun moyen de juger si le comportement d'un bogue apparaît seulement chaotique ou est réellement chaotique, alors il n'y a pas de pertinence dans la distinction entre un Bohr bug et un heisenbug, puisqu'on ne peut pas les déterminer.

Étymologie

Le mot est issu de la fusion de « Mandelbrot », nom de l'inventeur des fractales variables, et de « bug ».

Notes et références

Articles connexes

• Hacker

• Portail de la programmation informatique