Heisenkäfer – Wikipedia

Posted on by

Softwarefehler, der sich beim Debuggen zu ändern scheint

Im Computerprogrammierjargon, a heisenkäfer ist ein Softwarefehler, der zu verschwinden scheint oder sein Verhalten ändert, wenn man versucht, ihn zu untersuchen.[1] Der Begriff ist ein Wortspiel mit dem Namen von Werner Heisenberg, dem Physiker, der als erster den Beobachtereffekt der Quantenmechanik behauptete, der besagt, dass die Beobachtung eines Systems unweigerlich seinen Zustand ändert. In der Elektronik ist der traditionelle Begriff Sondeneffekt, bei dem das Anbringen einer Prüfspitze an einem Gerät sein Verhalten ändert.

Ähnliche Begriffe, wie z bohrkäfer, Mandelkäfer,[2][3][4]Hinterkäfer, und Schrödinbug[5][6] (siehe Abschnitt zu verwandten Begriffen) wurden gelegentlich für andere Arten von ungewöhnlichen Softwarefehlern vorgeschlagen, manchmal im Scherz;[7][8] jedoch im Gegensatz zum Begriff heisenkäfer, sie sind nicht allgemein bekannt oder verwendet.[9][original research?]

Beispiele[edit]

Heisenbugs treten auf, weil übliche Versuche, ein Programm zu debuggen, wie das Einfügen von Ausgabeanweisungen oder das Ausführen mit einem Debugger, normalerweise den Nebeneffekt haben, das Verhalten des Programms auf subtile Weise zu ändern, wie zum Beispiel die Speicheradressen von Variablen und das Timing zu ändern seiner Ausführung.

Ein häufiges Beispiel für einen Heisenbug ist ein Fehler, der auftritt, wenn das Programm mit einem optimierenden Compiler kompiliert wird, aber nicht, wenn das gleiche Programm ohne Optimierung kompiliert wird (wie es oft gemacht wird, um es mit einem Debugger zu untersuchen). Beim Debuggen werden häufig Werte, die ein optimiertes Programm normalerweise in Registern halten würde, in den Hauptspeicher verschoben. Dies kann sich beispielsweise auf das Ergebnis von Gleitkommavergleichen auswirken, da der Wert im Speicher einen kleineren Bereich und eine geringere Genauigkeit als der Wert im Register haben kann. In ähnlicher Weise können Heisenbugs durch Nebeneffekte in Testausdrücken verursacht werden, die in Laufzeit-Assertions in Sprachen wie C und C++ verwendet werden, wobei der Testausdruck nicht ausgewertet wird, wenn Assertionen im Produktionscode mit dem Befehl deaktiviert werden NDEBUG Makro.

Andere häufige Ursachen für Heisenbugs sind die Verwendung des Wertes einer nicht initialisierten Variablen (die ihre Adresse oder ihren Anfangswert während des Debuggens ändern kann) oder das Folgen eines ungültigen Zeigers (der beim Debuggen auf eine andere Stelle zeigen kann). Debugger erlauben auch häufig die Verwendung von Breakpoints oder stellen andere Benutzeroberflächen bereit, die dazu führen, dass zusätzlicher Quellcode (z. B. Eigenschafts-Accessoren) heimlich ausgeführt wird, was wiederum den Zustand des Programms ändern kann.[10]

Zeit kann auch ein Faktor bei heisenbugs sein, insbesondere bei Multithread-Anwendungen. Das Ausführen eines Programms unter der Steuerung eines Debuggers kann die Ausführungszeit des Programms im Vergleich zur normalen Ausführung ändern. Zeitkritische Fehler wie Race-Conditions treten möglicherweise nicht auf, wenn das Programm durch einstufige Quellzeilen im Debugger verlangsamt wird. Dies trifft insbesondere dann zu, wenn das Verhalten eine Interaktion mit einer Entität beinhaltet, die nicht unter der Kontrolle eines Debuggers steht, beispielsweise beim Debuggen der Netzwerkpaketverarbeitung zwischen zwei Maschinen und nur einer unter der Kontrolle des Debuggers.

Heisenbugs können als Beispiele für den Beobachtereffekt in der Informationstechnologie angesehen werden. Frustrierte Programmierer machen vielleicht humorvoll die Mondphase für einen Heisenkäfer verantwortlich,[11] oder (wenn es nur einmal aufgetreten ist) kann es als Soft Error aufgrund von Alphateilchen oder kosmischer Strahlung, die die Hardware beeinflussen, wegerklären, ein gut dokumentiertes Phänomen, das als Einzelereigniseffekte bekannt ist.

Verwandte Begriffe[edit]

EIN bohrkäfer, im Gegensatz dazu, ist ein “guter, solider Fehler”. Wie das deterministische Bohr-Atommodell ändern sie ihr Verhalten nicht und sind relativ leicht zu erkennen.[12][13]

EIN Mandelkäfer (benannt nach dem Fraktal von Benoît Mandelbrot) ist ein Fehler, dessen Ursachen so komplex sind, dass er sich einer Reparatur entzieht oder sein Verhalten chaotisch oder sogar nicht deterministisch erscheinen lässt.[2] Der Begriff bezieht sich auch auf einen Fehler, der fraktales Verhalten (d. h. Selbstähnlichkeit) zeigt, indem er mehr Fehler aufdeckt (je tiefer ein Entwickler in den Code eindringt, um ihn zu beheben, desto mehr Fehler finden sie).[citation needed]

EIN Schrödinbug oder Schrödinkäfer (benannt nach Erwin Schrödinger und seinem Gedankenexperiment) ist ein Fehler, der sich beim Ausführen von Software manifestiert, nachdem ein Programmierer bemerkt hat, dass der Code gar nicht hätte funktionieren sollen.[5]

EIN Hinterkäfer[14] (benannt nach der Hindenburg-Katastrophe) ist ein Bug mit katastrophalem Verhalten.

EIN higgs-bugson[15][16] (benannt nach dem Higgs-Boson-Teilchen) ist ein Fehler, dessen Existenz aufgrund anderer beobachteter Bedingungen (meist vage verwandte Protokolleinträge und anekdotische Benutzerberichte) vorhergesagt wird, aber in einer Entwicklung oder einem Test schwer, wenn nicht unmöglich, künstlich zu reproduzieren ist Umgebung. Der Begriff kann sich auch auf einen Fehler beziehen, der im Code offensichtlich ist (mathematisch bewiesen), aber in der Ausführung nicht sichtbar ist (aber schwer oder unmöglich tatsächlich zu finden ist).

Etymologie[edit]

Der Begriff wurde auch 1985 von Jim Gray in einem Artikel über Softwarefehler verwendet[17] (und wird ihm wegen dieser Veröffentlichung manchmal fälschlicherweise zugeschrieben) und auch 1986 von Jonathan Clark und Zhahai Stewart auf der Mailingliste (später Usenet Newsgroup) comp.risks.[18]

Bruce Lindsay, ein Forscher bei IBM, bestätigte 2004 in einem ACM-Queue-Interview, dass er bei der ursprünglichen Definition des Heisenbug anwesend war.[19]

Ein früheres Erscheinen in ACM-Publikationen stammt aus dem Jahr 1983.[20]

Auflösung[edit]

Heisenbugs sind schwer zu identifizieren und zu beheben; oft führt der Versuch, sie zu lösen, zu weiteren unerwarteten Verhaltensweisen. Da sich das Problem als Ergebnis eines separaten, zugrunde liegenden Fehlers manifestiert, kann das Verhalten während des Debuggens schwer vorherzusagen und zu analysieren sein. Insgesamt sollte die Zahl der identifizierten Heisenbugs mit zunehmender Reife einer Software sinken.[21]

Siehe auch[edit]

Verweise[edit]

  1. ^ “Die Jargon-Datei: heisenbug”.
  2. ^ ein B “Die Jargon-Datei: Mandelbug”. Catb.org. Abgerufen 2013-09-05.
  3. ^ Raymond, Eric S.; Das neue Hacker-Wörterbuch, 3. Auflage, 1996
  4. ^ Clarke, Arthur C., Der Geist von den Grand Banks, Bantam-Bücher, 1990
  5. ^ ein B “Die Jargon-Datei: Schroedinbug”. Catb.org. Abgerufen 2013-09-05.
  6. ^ Raymond, Eric S.; Das neue Hacker-Wörterbuch, 3. Auflage, 1996
  7. ^ Der folgende Artikel untersucht die verschiedenen in der Literatur vorgeschlagenen Definitionen von Bohrbug, Mandelbug und Heisenbug sowie die Aussagen zu den Beziehungen zwischen diesen Fehlertypen: Grottke, Michael; und Trivedi, Kishor S.; Softwarefehler, Softwarealterung und Softwareverjüngung, Zeitschrift der Reliability Engineering Association of Japan, vol. 27, Nr. 7, S. 425–438, 2005.
  8. ^ Grottke, Michael; und Trivedi, Kishor S.; Bugs bekämpfen: Entfernen, erneut versuchen, replizieren und verjüngen, IEEE-Computer vol. 40, nein. 2 (Februar 2007), S. 107–109
  9. ^ Eine Google Books-Suche vom Februar 2012 liefert etwa 70 Treffer für “schroedinbug”, 100 für “mandelbug”, 400 für “bohrbug” oder “heisenbug”.
  10. ^ “Java toString() überschreiben mit Initialisierung als Nebeneffekt” Archiviert 30.12.2014 auf der Wayback Machine
  11. ^ CATB.org, “Mondphase”
  12. ^ Goshgarian, Gary; Sprache erkunden, HarperCollins College Publishers, 1995
  13. ^ “Solche vorübergehenden Softwarefehler haben den skurrilen Namen ‘Heisenbug’ bekommen, weil sie bei einer erneuten Untersuchung verschwinden. ‘Bohrbugs’ sind dagegen gute solide Fehler.” (IEEE Computer Group News, Band 24, Nummern 7–12, 1991)
  14. ^ “Hinden Bug”.[better source needed]
  15. ^ “Neuer Programmier-Jargon”. 20. Juli 2012.
  16. ^ “20 urkomische Programmier-Jargon-Phrasen, die Sie verwenden sollten, wenn Sie mit Ingenieuren sprechen”.
  17. ^ Gray, Jim (1985). “Warum stoppen Computer und was kann man dagegen tun?”. Technischer Bericht 85.7. Tandem-Computer.
  18. ^ (16. Dezember 1986) RISIKEN VERDAUUNG 4.30 – (23. Dezember 1986) RISIKEN VERDAUEN 4.34, moderiert von Peter G. Neumann
  19. ^ ““A Conversation with Bruce Lindsay”, ACM Queue Vol. 2, no. 8 – November 2004″. Queue.acm.org. Abgerufen 2013-09-05.
  20. ^ Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on High-Level Debugging, Pacific Grove, Kalifornien, 20.–23. März 1983, Verband für Computermaschinen, 1983, Google Büchersuche:

    Dies ist das Heisenberg-Unsicherheitsprinzip, wie es beim Debuggen angewendet wird (ein Fall eines solchen Fehlers wurde von einem Teilnehmer als “Heisenbug” bezeichnet).

    Auch zitiert in LeBlanc, Richard J.; Robbins, Arnold D.; Ereignisgesteuerte Überwachung verteilter Programme, in Proceedings der IEEE 5th International Conference on Distributed Computing Systems (ICDCS), IEEE Computer Society, Computer Society Press, 1985, S. 515-522 Google Büchersuche:

    Dies ist das Heisenberg-Unsicherheitsprinzip, das auf das Debugging angewendet wird, manchmal auch als “Heisenbug”-Prinzip bezeichnet [ACM83].
  21. ^ P., Birman, Kenneth (2005). Zuverlässige verteilte Systeme: Technologien, Webdienste und Anwendungen. New York: Springer. ISBN 0387276017. OCLC 225378026.

Externe Links[edit]