L'immense majorité des bugs que nous subissons tous les jours trouve une explication rationnelle assez facilement. Une autre catégorie, heureusement extrêmement rare est celle des bugs dits "mystiques". Prenez les logs de tout système complexe et fortement chargé tels un serveur d'application ou un moniteur transactionnel : je vous prédis que vous y trouvez toujours sur une période suffisante des messages d'erreur étranges et non reproductibles...

Définition

Je nomme « bug mystique » un bug non reproductible, c'est à dire se produisant aléatoirement et pour des raisons inconnues.

Etymologie

Ce terme, issu de l'argot informatique et identique dans plusieurs langues ("Mystical bug" en Anglais) traduit parfaitement le coté ésotérique de ces étrangetés.

Le paradoxe

Pourtant, quoi de plus antinomique que d'un coté l'informatique et la programmation, issues des mathématiques (un programme étant une formule mathématique) et de l'autre le monde opaque de l'Incertain, du Hasard, du Destin ? Il est pourtant difficile en informatique de générer le hasard à volonté : les algorithmes des générateurs pseudo aléatoires sont complexes et utilisent de nombreuses données issues de l'environnement du calculateur comme l'heure, le mouvement de la souris pour un résultat souvent médiocre (des suites identiques apparaissent souvent). A l'opposé, les bugs mystiques semble apparaître aléatoirement car c'est leur nature : ils sont non reproductibles et peuvent subvenir n'importe quand et souvent à partir de situations d'origine a priori identiques.

Potentialité des bugs mystiques

Un informatien a dit un jour que certains bugs pouvaient se produire statistiquement une fois par siècle, c'est à dire sur une période au moins 5 à 10 fois supérieures à la durée de vie du programme lui-même. Je pense que c'est exact. Certains bugs mystiques peuvent ne jamais apparaître et rester tapis au fin fond d'obscurs tests ou boucles dont les conditions sont si improbables qu'il ne se produira jamais effectivement bien qu'il existe potentiellement.

Les causes des bugs mystiques

Un bug mystique peut se produire en autres :

• A cause des données à traiter : Dans le cas de l'exécution d'une primitive avec des arguments extrêmement particuliers par exemple.

• A cause d'un problème physique comme le changement simultané de plusieurs bits en mémoire vive, une erreur de lecture d'un support physique, une micro-coupure électrique, un bug matériel du processeur ou d'autres composants électroniques...

• A cause du code lui-même : bug du compilateur ou d'une machine virtuelle, bug dans le langage, utilisation inappropriée de fonctions spéciales... J'ai déjà vu des commentaires dans des sources Pro*C du type "Ne pas supprimer ce commentaire sinon le programme plante" qui ne mentaient pas, des caractères spéciaux ou écrits en hexadécimal produisant des effets imprévus à la compilation ou à l'exécution...

• A cause de la gestion de la mémoire : écrasement de segments mémoire de données par du code ou le contraire. Ce genre de bug sont souvent à la base des "exploits" utilisés par les craker pour casser sécurisés.

• A cause de problèmes passifs (ne produisant pas de bugs) de plusieurs modules ou API et qui, utilisés ensemble, se combinent pour faire émerger un nouveau bug actif.

• A cause du multi-tâches : à mon avis, la source principale de bugs mystiques dans les langages contemporains comme le Java. Malgré les outils de verrous proposés par ces langages, il est souvent difficile d'éviter totalement les situations imprévues et d'accès concurrents à des ressources partagées en mémoire.

• A cause de la gestion des transactions : Il faut utiliser correctement les outils de gestion de concurrence (ACID) pour éviter les événements imprévus lors de l'accès à une ressource comme une base de donnée, un MOM, un système externe etc... Ce type de composant peut avoir un comportement différent selon le vendeur (un accès concurrent dans une base de donnée peut lever une erreur ou se mettre en attente du verrou par exemple).

• A cause des problèmes de synchronisation inter transactionnels : Imaginez qu'un utilisateur A demande une fiche client dans une transaction propre. Il lit la fiche plusieurs minutes puis décide de modifier la donnée X. Entre temps, un utilisateur B a modifié la donnée Y dans une transaction de mise à jour terminée. Si la transaction de mise à jour envoie toutes les données en une seule fois (mode bulk), la mise à jour de l'utilisateur B sera écrasée par celles de l'utilisateur A et pourtant, chaque transaction se passe correctement et aucun accès concurrent n'est constaté.

• A cause des "dead locks" : un dead lock est un blocage définitif de deux taches se produisant dans le cas très particuliers d'accès concurrent à deux ressources distinctes dans un ordre précis (le thread 1 accède à la ressource A puis B et le thread 2 accède à la ressource B puis A en même temps que 1).

• A cause de nombreuses autres raisons comme des effets de bords rares etc.

Conclusion : le jardin secret du programme

Le bug mystique donne une nouvelle dimension aux systèmes d'information et semble faire émerger une sorte de chaos, une conscience qui dépasse le cadre créé par l'humain. Les bugs mystiques se cachent dans le jardin secret du programme, hors de portée de la pensée et de la compréhension des développeurs. Ils agacent, non seulement à cause du bug lui-même mais surtout à cause de l'impression que le programme cache quelque chose, qu'il possède le pouvoir mystérieux de sortir de son chapeau l'un de ces bugs à sa guise.