Bug (informatique)

Les bugs peuvent amener les logiciels à tenter d'effectuer des opérations impossibles à réaliser (exceptions) : division par zéro, recherche d'informations inexistantes. Ces opérations - qui ne sont jamais utilisées lors de fonctionnement correct du logiciel - déclenchent un mécanisme à la fois matériel et logiciel qui met alors hors service le logiciel défaillant, ce qui provoque un crash informatique ou un déni de service.

Un chien de garde est un dispositif électronique autonome qui sert à déceler les dysfonctionnements. Ce mécanisme est souvent utilisé avec les systèmes critiques et l'informatique industrielle.

L'écran bleu de la mort est, dans le langage populaire, le nom donné au message de mise hors service des systèmes d'exploitation Microsoft Windows, qui s'affiche lorsqu'une exception est décelée au cœur du système d'exploitation. La Kernel panic est le message affiché dans des conditions similaires sur les systèmes d'exploitation UNIX.

Une fuite de mémoire est un dysfonctionnement dû à un bug dans les opérations d'allocation de mémoire. Avec ce dysfonctionnement, la quantité de mémoire utilisée par le logiciel défaillant va en augmentant continuellement. Si le logiciel défaillant arrive à utiliser la quasi-totalité de la mémoire disponible, celui-ci gêne alors le déroulement des autres logiciels et les entraîne à des dysfonctionnements.

Une erreur de segmentation est un dysfonctionnement dû à un bug dans des opérations de manipulations de pointeurs ou d'adresses mémoire. Le logiciel défaillant va tenter de lire ou d'écrire des informations dans un emplacement de mémoire (segment) qui n'existe pas ou qui ne lui est pas autorisé. Le mécanisme de détection des exceptions provoque alors la mise hors service du logiciel défaillant.

Un dépassement d'entier est un dysfonctionnement dû à un bug dans des opérations de calcul mathématique. Le logiciel défaillant va tenter d'effectuer un calcul dont le résultat est supérieur à la valeur maximum autorisée. Le mécanisme de détection des exceptions provoque alors la mise hors service du logiciel défaillant.

Un dépassement de tampon est un dysfonctionnement dû à un bug. Un logiciel qui doit écrire des informations dans un emplacement déterminé et limité de mémoire (mémoire tampon) dépasse les limites de cet emplacement et va alors écrire des informations sur un emplacement destiné à un autre usage, cette modification inopinée entraine une exécution erratique du logiciel, qui peut se terminer par une erreur de segmentation ou un dépassement de capacité. C'est une faille de sécurité courante des serveurs qui est souvent exploitée par les pirates informatiques. voir Exploit.

Un dépassement de pile est un dysfonctionnement dans lequel la taille de la pile d'exécution d'un logiciel dépasse la capacité de la mémoire tampon qui la contient, ce qui provoque des dysfonctionnements similaires à un dépassement de tampon. La pile d'exécution est une structure de données stockée en mémoire qui contient l'état du déroulement des automatismes du logiciel (voir processus (informatique)), cette structure est enregistrée dans une mémoire tampon dont la taille est sur-dimensionnée. Un dépassement de pile résulte d'un déroulement erroné à la suite d'un bug.

Une situation de compétition (anglais race condition) est un dysfonctionnement dû à un bug, qui fait que dans un même logiciel deux automatismes qui travaillent simultanément donnent des résultats différents suivant l'automatisme qui termine avant l'autre.

Un interblocage (anglais deadlock) est un dysfonctionnement durant lequel lorsque plusieurs automatismes s'attendent mutuellement, c'est-à-dire qu'ils attendent chacun que l'autre libère les ressources qu'il utilise pour poursuivre. Les ressources restent verrouillées durant les attentes, ce qui peut bloquer d'autres automatismes et par effet domino bloquer l'ensemble du système. Un mécanisme de prévention provoque l'annulation de l'opération lorsque la durée d'attente dépasse le délai admissible (anglais timeout).

Plus le code est complexe, plus il est difficile de localiser un bug. Des bugs qui dépendent d'une combinaison de conditions imprévues et improbables sont particulièrement difficiles à localiser. Dans le folklore hacker il existe des catégories de bugs bizarres dont les noms humoristiques sont dérivés de ceux d'éminents scientifiques en physique quantique et en mathématique[12].

• Heisenbug : (du principe d'incertitude de Heisenberg) un bug qui disparaît ou se modifie quand on essaye de l'isoler.
• Mandelbug : (des ensembles de Mandelbrot) un bug dont les causes sont si obscures et complexes que le résultat est un comportement chaotique et non déterministe.
• Schrödinbug : (du chat de Schrödinger) un bug qui ne se manifeste pas jusqu'à ce que quelqu'un lise le code source, utilise le programme d'une façon peu ou pas usuelle et constate qu'il n'aurait jamais dû fonctionner.
• Bohr bug : Un bug répétable, qui se reproduit lorsqu'un ensemble - même inconnu - de conditions sont remplies[13].

L'exécution pas-à-pas d'un logiciel à l'aide d'un débogueur peut provoquer des Heisenbug du simple fait que le logiciel se déroule moins rapidement[13]. Et les situations de compétition peuvent entraîner des Mandelbug, où le comportement du programme est différent à chaque fois que celui-ci est exécuté[14].

Les bugs résultent d'erreurs humaines lors des travaux de spécification, de conception, de programmation et de tests de logiciel et de matériel informatique. La complexité grandissante des logiciels, les problèmes de communication, le manque de formation des ingénieurs et la pression des délais et des coûts durant les travaux d'ingénierie sont des facteurs qui tendent à augmenter le nombre de bugs[15].

Les tests de logiciels sont la première mesure pour contrer les bugs. Pour des raisons pratiques (coût des travaux et délais), il n'est pas possible de tester un logiciel dans toutes les conditions qu'il pourrait rencontrer lors de son utilisation et donc pas possible de contrer la totalité des bugs : un logiciel comme Microsoft Word compte 850 commandes et 1 600 fonctions, ce qui fait un total de plus de 500 millions de conditions à tester[16].

L'utilisation de langages de programmation de haut niveau, qui facilitent le travail de l'ingénieur, et la mise en application de conventions de rédaction sont d'autres techniques préventives destinées à diminuer le nombre de bugs.

Le débogage est l'activité qui consiste à diagnostiquer et corriger des bugs. Lors du débogage en ligne, l'ingénieur exécute le logiciel pas à pas et effectue après chaque pas une série de vérifications. Lors du débogage post-mortem, l'ingénieur examine un logiciel à la suite d'un crash informatique.

Lorsque le bug est décelé et corrigé après la distribution du logiciel, le fournisseur met souvent à disposition un patch, c'est-à-dire un kit qui remplace les parties défaillantes du logiciel par celles qui ont été corrigées.

Les ingénieurs utilisent souvent un système de suivi des bugs, c'est-à-dire un logiciel de base de données dans lequel sont inscrits les différents bugs ainsi que les travaux réalisés pour chacun :

• une personne (développeur, testeur, utilisateur...) qui voit quelque chose qui lui semble anormal remplit un formulaire, qui crée une entrée dans la base de données et lui affecte un numéro ;
• ensuite, un expert effectue une analyse, il regarde s'il s'agit réellement d'un bug ou d'une méprise (manuel pas clair par exemple, ou utilisateur mal formé) ;
• si une correction est possible (peut être aussi bien une correction dans le code qu'une précision à ajouter dans le manuel, une spécification à corriger, une traduction à améliorer...), la décision est prise de faire une correction ou pas, et avec quelle priorité. Le travail à faire est généralement affecté à quelqu'un en particulier ;
• puis, la personne désignée traite le problème, et indique que le problème est réglé ;
• généralement, une confirmation par une tierce personne (testeur, autre développeur, utilisateur...) est requise ;
• si tout va bien, le problème est clos. Sinon, le problème est rouvert et le cycle recommence.

De nombreux langages de programmation incluent des mécanismes de vérification des dysfonctionnements. Les instructions nécessaires aux vérifications sont ajoutées automatiquement au code machine ou au bytecode du logiciel lors de la compilation. Les instructions peuvent provoquer l'activation automatique du débogueur, le logiciel de diagnostic des bugs.

La revue de code consiste à soumettre le code source fraîchement développé à une tierce personne qui va le relire et rechercher des défauts.

Les tests logiciel sont la première mesure pour contrer les bugs. Ils consistent à utiliser le logiciel dans le plus de conditions possibles. Le but des tests est de déceler différents problèmes :

• le logiciel ne fait pas ce qu'il doit faire ;
• le logiciel fait quelque chose qu'il ne doit pas faire ;
• le logiciel fait quelque chose qui ne lui est pas demandé ;
• le logiciel ne fait pas bien ce qu'il doit faire (ex. : trop lentement[17]).

Les tests sont répétés plusieurs fois, à mesure de l'avancée de la programmation et des corrections, ceci afin de valider les corrections et déceler d'éventuels bugs de régression : des bugs survenus à la suite de la correction erronée d'un autre bug. Les tests peuvent être automatisés à l'aide de logiciels qui agissent à la place de l'utilisateur. Parfois un second logiciel est développé pour servir aux tests.

Les tests unitaires consistent à utiliser une fonction unique du logiciel en vue de déceler des dysfonctionnements. Les tests d'intégration consistent à utiliser un ensemble de fonctions en vue de contrôler la cohérence de l'ensemble. Les tests de validation consistent à utiliser l'ensemble du logiciel en vue d'évaluer son adéquation au besoin de l'acheteur.

Les tests unitaires et d'intégration sont typiquement effectués par l'ingénieur, tandis que les tests de validation sont typiquement effectués par l'acheteur ou son représentant.

Une autre mesure préventive pour éviter les bugs est la preuve formelle (ou démonstration mathématique) du fonctionnement du programme, de manière générique. Contrairement au test qui ne vérifie qu'un seul cas de fonctionnement donné, cette preuve cherche à assurer que le programme fonctionne dans tous les cas, quelles que soient les conditions d'utilisation. Mais toutes les techniques de vérification formelles sont lourdes et complexes. Dans l'absolu, on ne sait pas vérifier le bon fonctionnement d'un programme quelconque dans tous les cas. En revanche, il existe des méthodes de création de logiciels, qui, au cours de la création du logiciel, mettent en place des éléments de suivi du passage vers chaque étape intermédiaire entre les spécifications ou le cahier des charges du logiciel d'une part, et le programme final d'autre part. Grâce à ces éléments de suivi, des vérifications sont ensuite possibles, et des contraintes de respect de la spécification peuvent être imposées et verrouillées.

Dans les domaines où un bug causerait la mort d'êtres humains, (par exemple dans l'aéronautique), des méthodes lourdes et complexes sont utilisées pour prouver l'absence de bug dans le logiciel, lors de sa conception. Ainsi, le logiciel de contrôle du métro automatique ligne 14 à Paris a été à l'origine réalisé avec la notation Z. Pourtant, c'est la Méthode B qui a été utilisée pour en créer la version finale[18]. La méthode B est d'ailleurs considérée comme le meilleur outil pour garantir qu'un programme informatique est conforme aux spécifications de son comportement. En effet, l'utilisation de la Méthode B pour créer le programme conduit aussi (automatiquement) à démontrer mathématiquement la conformité du programme ainsi créé, qui devient donc par définition un théorème démontré.

Cependant, la complexité d'utilisation de cette méthode entraine un surcroit de travail tel, qu'un programmeur seul peut avoir besoin de 100 fois plus de temps pour créer un programme avec cette méthode que s'il avait créé le même programme de manière traditionnelle. Cela signifie alors que cela coute 100 fois plus cher de créer le programme avec cette méthode. En conséquence, malgré son efficacité, cette méthode n'est que très rarement utilisée, et il existe de nombreux domaines dans lesquels des bugs peuvent causer la mort d'êtres humains et où l'on se contente pourtant de créer des programmes bourrés de bugs, de manière traditionnelle, puis de faire des tests très rigoureux pour en éliminer la plupart. À partir du moment où la probabilité qu'un bug crée un dysfonctionnement qui tue des gens reste inférieure à la probabilité qu'une erreur humaine crée le même genre de dysfonctionnement, cela est souvent jugé « acceptable ». (Et le surcout entrainé par l'utilisation de la méthode B pour garantir que personne ne meurt est jugé inacceptable).

Pour le débogage[note 5] (de l'anglais : « debugging »), soit la recherche et la correction de bugs, les ingénieurs se servent d'un logiciel, le débogueur, ainsi que d'un système de suivi des bugs.

Le système de suivi des bugs sert à coordonner les travaux de débogage, il est utilisé pour collecter tous les dysfonctionnements constatés, inscrire les causes et les actions de correction effectuées et ainsi suivre l'avancement des corrections. Les causes peuvent être des bugs, mais aussi des défauts dans les paramètres de configuration ou des erreurs de manipulation. Le système de suivi des bugs est utilisé aussi bien par les usagers du logiciel défaillant que par les ingénieurs ou les administrateurs systèmes.

Le débogueur permet d'analyser l'état d'exécution d'un logiciel à un instant donné, les opérations en cours, les informations en mémoire, les fichiers ouverts, etc. Avec un débogueur en ligne, il est possible de suspendre l'exécution du logiciel à tout moment, d'analyser l'état, puis de continuer les traitements.

Avec un débogueur post-mortem, il est possible d'analyser l'état d'exécution d'un logiciel après un crash. L'analyse se fait sur la base d'un fichier qui contient la copie du contenu de la mémoire au moment du crash. Fichier appelé core dump sur les systèmes d'exploitation Unix.

Une version de logiciel est l'état d'un logiciel à une date donnée, y compris toutes les corrections et améliorations qui ont été faites jusqu'à cette date. La version est dite alpha ou beta lorsqu'elle correspond à l'état du logiciel avant la fin de la durée des tests. Une telle version est susceptible de contenir des bugs qui ont entretemps été décelés et corrigés.

Une fois un ou plusieurs défauts corrigés, ceux-ci sont regroupés dans un patch, un kit qui contient uniquement les composants du logiciel qui ont été corrigés. Il sera utilisé par toute personne qui possède une copie du logiciel pour y appliquer les corrections et le faire correspondre à une version donnée.

L'échec du vol inaugural de la fusée Ariane 5 en 1996 a pour origine un défaut dans les appareils d'avionique de la fusée, appareils utilisés avec succès pendant plusieurs années sur la fusée Ariane 4. Lors du décollage, l'appareil informatique qui calculait la position de la fusée en fonction de son accélération ne supporta pas les accélérations d'Ariane 5, 5 fois plus fortes que celles d'Ariane 4. Un dépassement d'entier provoqua le crash informatique de l'appareil. Aveuglé, le pilote automatique perdit le contrôle de la fusée, et un dispositif de sécurité provoqua son autodestruction quelques secondes après le décollage. C'est l'un des bugs informatiques les plus coûteux de l'histoire[19].

En 1962, la mission Mariner 1 a connu un incident similaire[20].

Dans les années 1980, un bug affectant le logiciel d'une machine de radiothérapie pilotée par un PDP-11, le Therac-25[21], a eu des conséquences tragiques, des patients reçurent des doses massives de radiation et au moins cinq en sont morts.

Le bug de l'an 2000, aussi appelé bug du millénaire : un ou plusieurs bugs dans un logiciel qui manipule des dates provoquent des dysfonctionnements lorsque les dates sont postérieures au 31 décembre 1999. Une des causes est que les calculs sur les dates se faisaient uniquement sur les deux derniers chiffres de l'année.

Les problèmes potentiels posés par la date du 31 décembre 1999 ont été anticipés la première fois par Bob Berner en 1971[22]. Ils ont provoqué une importante mobilisation des entreprises de génie logiciel quelques années avant la date butoir et le coût total des travaux de contrôle et de maintenance préventive est estimé à plus de 600 millions de dollars[23].

En 2002, le système informatique de l'hôpital St Mary's Mercy dans le Michigan a déclaré par erreur la mort de 8 500 patients qui étaient en fait encore vivants, envoyant à leur domicile une facture et une déclaration de décès, ainsi qu'une annonce de leur mort à leur société d'assurance et à la sécurité sociale américaine[24]. Il a fallu plusieurs semaines pour que ces décès soient annulés auprès des différentes administrations.

• Jean-Louis Boulanger, Mise en œuvre de la méthode B : Développement formel des logiciels sécuritaires de Meteor, 2013 (lire en ligne)

Voir aussi la catégorie Développement logiciel

• (en) La loi de Murphy appliquée à l'informatique
• Le premier bug