Bug logiciel inhabituel — Wikipédia

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és d'après le nom de scientifiques qui ont découvert des principes non intuitifs.

Selon la nature, la probabilité d'apparition ou la gravité, on trouve ainsi :

  • Schrödinbug ;
  • Heisenbug ;
  • Bohr bug ;
  • Mandelbug.

Schrödinbug

[modifier | modifier le code]

Un schrödinbug[1] (ou schroedinbug, graphie beaucoup plus courante en anglais) 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.

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

[modifier | modifier le code]

Le mot schrödinbug est un mot-valise composé de « Schrödinger », nom du physicien inventeur du concept du Chat de Schrödinger, et de « bug ».

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 électronique, le terme traditionnel est effet de sonde.

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 affichages 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 à 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++.

Sous 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 fonction 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

[modifier | modifier le code]

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.

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

[modifier | modifier le code]

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

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.[réf. nécessaire]

Étymologie

[modifier | modifier le code]

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

Notes et références

[modifier | modifier le code]
  1. (en) « schroedinbug », sur Jargon File,
  2. (en) « heisenbug », sur Jargon File,
  3. (en) « Next release », sur lists.gnu.org,
  4. (en) « Richard Stallman's Interview, Linuxcare Interviews »,
  5. (en) « possible race condition in linuxthreads-0.9 (*very* strange heisenbug Forwarded message), bug-glibc »,
  6. (en) « liarc loader has a heisenbug, bug-mit-scheme »,
  7. (en) « Bohr bug », sur Jargon File,
  8. (en) « update-menus dies », sur bugs.debian.org,
  9. (en) « mandelbug », sur Jargon File,
  10. (en) « Confirmed template parsing bug », sur gcc.gnu.org,
  11. (en) « non-local exit may cause wrong-type-arg error, bug-guile »,

Articles connexes

[modifier | modifier le code]