Il s'agit de documents de référence sur les Heisenbags. Nous parlons de leur apparence et de leur relation avec les ordinateurs centraux - les progéniteurs du cloud.
/ photo Lars Zimmermann CC BYHeisenbug (Heisenbug ou Heisenbug) est un terme qui décrit les erreurs qui modifient les propriétés lors du débogage de code. Autrement dit, ils disparaissent lors des tests et du débogage, mais apparaissent en production.
Le nom «Heisenbag» fait référence au
principe d'incertitude de Heisenberg de la mécanique quantique. D'une manière générale, il peut être décrit comme un changement inattendu des propriétés de l'objet observé à la suite de l'observation.
L'histoire
Le terme Heisenbug est considéré comme étant Bruce Lindsay, un employé du Centre de recherche IBM. Il a contribué au développement de bases de données relationnelles et a été impliqué dans le développement du moteur de base de données d'entreprise
IBM System R.En 1985, alors qu'ils étudiaient à l'Université de Berkeley, Bruce et
Jim Gray (James Nicholas Gray), un scientifique américain de la théorie des systèmes informatiques, ont
travaillé sur le système d'exploitation CAL-TSS. Il a été écrit spécifiquement pour le mainframe à deux processeurs
Control Process 6400 [
PDF , p. 3], sur lequel les militaires ont traité de grandes quantités de données.
Bien sûr, pendant le processus de développement, il y a eu des bugs. Mais plusieurs d'entre eux étaient spéciaux - dès que les ingénieurs ont essayé de les réparer, ils ont disparu. À cette époque, Lindsay étudiait seulement la physique et le principe de Heisenberg en particulier. Tout à coup, il est apparu à Lindsay - lui et Gray sont devenus les témoins d'un phénomène similaire: les erreurs ont disparu, car l'observation a affecté les propriétés de l'objet. D'où le nom «heisenbag».
Lindsay a raconté cette histoire
dans une interview avec des représentants de l'
Association of Computing Engineering (ACM) en 2003.
Exemples Heisenbug
Les utilisateurs du réseau et des plateformes thématiques comme Stack Overflow ont partagé quelques exemples de heisenbags rencontrés dans leurs projets. L'un des résidents de SO a essayé de calculer l'aire de la figure entre deux courbes avec une précision de trois décimales. Pour déboguer l'algorithme en C ++, il a ajouté la ligne:
cout << current << endl;
Mais dès qu'il l'a commenté, le code a cessé de fonctionner et a bouclé. Le programme
était le suivant :
#include <iostream> #include <cmath> using namespace std; double up = 19.0 + (61.0/125.0); double down = -32.0 - (2.0/3.0); double rectangle = (up - down) * 8.0; double f(double x) { return (pow(x, 4.0)/500.0) - (pow(x, 2.0)/200.0) - 0.012; } double g(double x) { return -(pow(x, 3.0)/30.0) + (x/20.0) + (1.0/6.0); } double area_upper(double x, double step) { return (((up - f(x)) + (up - f(x + step))) * step) / 2.0; } double area_lower(double x, double step) { return (((g(x) - down) + (g(x + step) - down)) * step) / 2.0; } double area(double x, double step) { return area_upper(x, step) + area_lower(x, step); } int main() { double current = 0, last = 0, step = 1.0; do { last = current; step /= 10.0; current = 0; for(double x = 2.0; x < 10.0; x += step) current += area(x, step); current = rectangle - current; current = round(current * 1000.0) / 1000.0; //cout << current << endl; //<-- COMMENT BACK IN TO "FIX" BUG } while(current != last); cout << current << endl; return 0; }
L'essence du heisenbug : lorsqu'il n'y a pas d'impression, le programme effectue des comparaisons avec une grande précision dans les registres du processeur. De plus, la précision du résultat dépasse les capacités de double. Pour générer la valeur, le compilateur renvoie le résultat des calculs dans la mémoire principale - tandis que la partie fractionnaire est supprimée. Et la comparaison ultérieure dans while conduit au résultat correct. Lorsqu'une ligne est mise en commentaire, il n'y a pas de troncature implicite de la partie fractionnaire. Pour cette raison, les deux valeurs de while se révèlent toujours inégales l'une de l'autre. Pour résoudre le problème, l'un des participants à la discussion a suggéré d'utiliser une comparaison approximative des nombres à virgule flottante.
Une autre histoire sur le heisenbug a été
partagée par des ingénieurs travaillant avec l'environnement de langage
Smalltalk-80 sur Unix. Ils ont remarqué que le système se bloquait si vous le laissiez inactif pendant un certain temps. Mais après avoir déplacé le curseur de la souris, tout a fonctionné à nouveau comme d'habitude.
Le problème venait du planificateur Unix, qui abaissait la priorité des tâches inactives. À un moment donné, la priorité a été tellement réduite que les processus dans Smalltalk n'ont pas eu le temps de se terminer. La pile de tâches s'est agrandie et a suspendu le programme. Lorsque l'utilisateur a déplacé le curseur, le système d'exploitation a restauré la priorité et tout est revenu à la case départ.
Autres * bugs
Il existe un certain nombre de termes qui décrivent toutes sortes d'erreurs: Borbag, Mandelbug, Schrödinbag.
Borbag , l'opposé de Heisenbug, est une erreur courante facile à trouver et à corriger. Nommé d'après Niels Bohr, qui en 1913 a proposé un modèle simple et compréhensible de la structure de l'atome. Selon ce modèle, les électrons d'un atome se déplacent sur certaines orbites, ce qui signifie que leur impulsion et leur rayon de mouvement peuvent être prédits. De même, l'apparition de Borbags peut être prédite si les conditions nécessaires sont créées pour eux.
/ photo OLCF à ORNL CC BYSchroedinbag est une erreur qui existe et qui n'existe pas en même temps, jusqu'à ce que le développeur la regarde. L'erreur a été nommée en l'honneur d'une célèbre
expérience de pensée .
Quant au
Mandelbug , il s'agit d'une erreur à cause de laquelle le système se comporte de manière erratique et imprévisible. Le phénomène tire son nom du physicien, mathématicien et créateur de la géométrie fractale
Benoit Mandelbrot .
Quel est le résultat
Il existe de
nombreux exemples de Heisenbags (et d'autres * bugs). Ils sont très difficiles à trouver, mais les causes sont généralement courantes: une variable non initialisée, des erreurs de synchronisation dans un environnement multithread ou des problèmes avec
des algorithmes de
suppression de code mort . Il s'avère que pour faire face à de telles erreurs, elles doivent être supprimées même au stade de la conception de l'application.
Du blog d'entreprise IaaS: