[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/wiki25\/2021\/11\/03\/heisenkafer-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/wiki25\/2021\/11\/03\/heisenkafer-wikipedia\/","headline":"Heisenk\u00e4fer \u2013 Wikipedia","name":"Heisenk\u00e4fer \u2013 Wikipedia","description":"Softwarefehler, der sich beim Debuggen zu \u00e4ndern scheint Im Computerprogrammierjargon, a heisenk\u00e4fer ist ein Softwarefehler, der zu verschwinden scheint oder","datePublished":"2021-11-03","dateModified":"2021-11-03","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/wiki25\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/wiki25\/author\/lordneo\/","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Enzyklop\u00e4die","logo":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":100,"height":100},"url":"https:\/\/wiki.edu.vn\/wiki25\/2021\/11\/03\/heisenkafer-wikipedia\/","wordCount":3337,"articleBody":"Softwarefehler, der sich beim Debuggen zu \u00e4ndern scheintIm Computerprogrammierjargon, a heisenk\u00e4fer ist ein Softwarefehler, der zu verschwinden scheint oder sein Verhalten \u00e4ndert, 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 \u00e4ndert.  In der Elektronik ist der traditionelle Begriff Sondeneffekt, bei dem das Anbringen einer Pr\u00fcfspitze an einem Ger\u00e4t sein Verhalten \u00e4ndert.\u00c4hnliche Begriffe, wie z bohrk\u00e4fer, Mandelk\u00e4fer,[2][3][4]Hinterk\u00e4fer, und Schr\u00f6dinbug[5][6]  (siehe Abschnitt zu verwandten Begriffen) wurden gelegentlich f\u00fcr andere Arten von ungew\u00f6hnlichen Softwarefehlern vorgeschlagen, manchmal im Scherz;[7][8]  jedoch im Gegensatz zum Begriff heisenk\u00e4fer, sie sind nicht allgemein bekannt oder verwendet.[9][original research?]Beispiele[edit]Heisenbugs treten auf, weil \u00fcbliche Versuche, ein Programm zu debuggen, wie das Einf\u00fcgen von Ausgabeanweisungen oder das Ausf\u00fchren mit einem Debugger, normalerweise den Nebeneffekt haben, das Verhalten des Programms auf subtile Weise zu \u00e4ndern, wie zum Beispiel die Speicheradressen von Variablen und das Timing zu \u00e4ndern seiner Ausf\u00fchrung.Ein h\u00e4ufiges Beispiel f\u00fcr 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\u00e4ufig Werte, die ein optimiertes Programm normalerweise in Registern halten w\u00fcrde, 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 \u00e4hnlicher Weise k\u00f6nnen Heisenbugs durch Nebeneffekte in Testausdr\u00fccken 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\u00e4ufige Ursachen f\u00fcr Heisenbugs sind die Verwendung des Wertes einer nicht initialisierten Variablen (die ihre Adresse oder ihren Anfangswert w\u00e4hrend des Debuggens \u00e4ndern kann) oder das Folgen eines ung\u00fcltigen Zeigers (der beim Debuggen auf eine andere Stelle zeigen kann).  Debugger erlauben auch h\u00e4ufig die Verwendung von Breakpoints oder stellen andere Benutzeroberfl\u00e4chen bereit, die dazu f\u00fchren, dass zus\u00e4tzlicher Quellcode (z. B. Eigenschafts-Accessoren) heimlich ausgef\u00fchrt wird, was wiederum den Zustand des Programms \u00e4ndern kann.[10]Zeit kann auch ein Faktor bei heisenbugs sein, insbesondere bei Multithread-Anwendungen.  Das Ausf\u00fchren eines Programms unter der Steuerung eines Debuggers kann die Ausf\u00fchrungszeit des Programms im Vergleich zur normalen Ausf\u00fchrung \u00e4ndern.  Zeitkritische Fehler wie Race-Conditions treten m\u00f6glicherweise 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\u00e4t 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\u00f6nnen als Beispiele f\u00fcr den Beobachtereffekt in der Informationstechnologie angesehen werden.  Frustrierte Programmierer machen vielleicht humorvoll die Mondphase f\u00fcr einen Heisenk\u00e4fer 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\u00e4ren, ein gut dokumentiertes Ph\u00e4nomen, das als Einzelereigniseffekte bekannt ist.Verwandte Begriffe[edit]EIN bohrk\u00e4fer, im Gegensatz dazu, ist ein “guter, solider Fehler”.  Wie das deterministische Bohr-Atommodell \u00e4ndern sie ihr Verhalten nicht und sind relativ leicht zu erkennen.[12][13]EIN Mandelk\u00e4fer (benannt nach dem Fraktal von Beno\u00eet 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\u00e4sst.[2]  Der Begriff bezieht sich auch auf einen Fehler, der fraktales Verhalten (d. h. Selbst\u00e4hnlichkeit) 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\u00f6dinbug oder Schr\u00f6dink\u00e4fer (benannt nach Erwin Schr\u00f6dinger und seinem Gedankenexperiment) ist ein Fehler, der sich beim Ausf\u00fchren von Software manifestiert, nachdem ein Programmierer bemerkt hat, dass der Code gar nicht h\u00e4tte funktionieren sollen.[5]EIN Hinterk\u00e4fer[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\u00e4ge und anekdotische Benutzerberichte) vorhergesagt wird, aber in einer Entwicklung oder einem Test schwer, wenn nicht unm\u00f6glich, k\u00fcnstlich zu reproduzieren ist Umgebung.  Der Begriff kann sich auch auf einen Fehler beziehen, der im Code offensichtlich ist (mathematisch bewiesen), aber in der Ausf\u00fchrung nicht sichtbar ist (aber schwer oder unm\u00f6glich tats\u00e4chlich zu finden ist).Etymologie[edit]Der Begriff wurde auch 1985 von Jim Gray in einem Artikel \u00fcber Softwarefehler verwendet[17]  (und wird ihm wegen dieser Ver\u00f6ffentlichung manchmal f\u00e4lschlicherweise zugeschrieben) und auch 1986 von Jonathan Clark und Zhahai Stewart auf der Mailingliste (sp\u00e4ter Usenet Newsgroup) comp.risks.[18]Bruce Lindsay, ein Forscher bei IBM, best\u00e4tigte 2004 in einem ACM-Queue-Interview, dass er bei der urspr\u00fcnglichen Definition des Heisenbug anwesend war.[19]Ein fr\u00fcheres Erscheinen in ACM-Publikationen stammt aus dem Jahr 1983.[20]Aufl\u00f6sung[edit]Heisenbugs sind schwer zu identifizieren und zu beheben;  oft f\u00fchrt der Versuch, sie zu l\u00f6sen, zu weiteren unerwarteten Verhaltensweisen.  Da sich das Problem als Ergebnis eines separaten, zugrunde liegenden Fehlers manifestiert, kann das Verhalten w\u00e4hrend 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]^ “Die Jargon-Datei: heisenbug”.^ ein B “Die Jargon-Datei: Mandelbug”.  Catb.org.  Abgerufen 2013-09-05.^ Raymond, Eric S.; Das neue Hacker-W\u00f6rterbuch, 3. Auflage, 1996^ Clarke, Arthur C., Der Geist von den Grand Banks, Bantam-B\u00fccher, 1990^ ein B “Die Jargon-Datei: Schroedinbug”.  Catb.org.  Abgerufen 2013-09-05.^ Raymond, Eric S.; Das neue Hacker-W\u00f6rterbuch, 3. Auflage, 1996^ 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\u00fcngung, Zeitschrift der Reliability Engineering Association of Japan, vol.  27, Nr. 7, S. 425\u2013438, 2005.^ Grottke, Michael;  und Trivedi, Kishor S.; Bugs bek\u00e4mpfen: Entfernen, erneut versuchen, replizieren und verj\u00fcngen, IEEE-Computer vol.  40, nein.  2 (Februar 2007), S. 107\u2013109^ Eine Google Books-Suche vom Februar 2012 liefert etwa 70 Treffer f\u00fcr “schroedinbug”, 100 f\u00fcr “mandelbug”, 400 f\u00fcr “bohrbug” oder “heisenbug”.^ “Java toString() \u00fcberschreiben mit Initialisierung als Nebeneffekt” Archiviert 30.12.2014 auf der Wayback Machine^ CATB.org, “Mondphase”^ Goshgarian, Gary; Sprache erkunden, HarperCollins College Publishers, 1995^ “Solche vor\u00fcbergehenden 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\u201312, 1991)^ “Hinden Bug”.[better\u00a0source\u00a0needed]^ “Neuer Programmier-Jargon”.  20. Juli 2012.^ “20 urkomische Programmier-Jargon-Phrasen, die Sie verwenden sollten, wenn Sie mit Ingenieuren sprechen”.^ Gray, Jim (1985). “Warum stoppen Computer und was kann man dagegen tun?”. Technischer Bericht 85.7.  Tandem-Computer.^ (16. Dezember 1986) RISIKEN VERDAUUNG 4.30 – (23. Dezember 1986) RISIKEN VERDAUEN 4.34, moderiert von Peter G. Neumann^ ““A Conversation with Bruce Lindsay”, ACM Queue Vol. 2, no. 8 – November 2004″.  Queue.acm.org.  Abgerufen 2013-09-05.^ Proceedings of the ACM SIGSOFT\/SIGPLAN Software Engineering Symposium on High-Level Debugging, Pacific Grove, Kalifornien, 20.\u201323. M\u00e4rz 1983, Verband f\u00fcr Computermaschinen, 1983, Google B\u00fcchersuche: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 \u00dcberwachung 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\u00fcchersuche:Dies ist das Heisenberg-Unsicherheitsprinzip, das auf das Debugging angewendet wird, manchmal auch als “Heisenbug”-Prinzip bezeichnet [ACM83].^ P., Birman, Kenneth (2005). Zuverl\u00e4ssige verteilte Systeme: Technologien, Webdienste und Anwendungen.  New York: Springer.  ISBN 0387276017.  OCLC 225378026.Externe Links[edit]"},{"@context":"http:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki25\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki25\/2021\/11\/03\/heisenkafer-wikipedia\/#breadcrumbitem","name":"Heisenk\u00e4fer \u2013 Wikipedia"}}]}]