heisenbug

___ qstntxt ___

Mein angeblich deterministisches Programm erzeugt eine von ein paar leicht unterschiedlichen Ausgaben in verschiedenen Läufen. Die Eingabe, der Compiler und der Computer sind unverändert. Ich bin mir nicht sicher, welche Ausgabe richtig ist, weil sie immer vernünftig aussieht.

Wie könnte das möglich sein? Neben einem irren Aufruf von rand ()?

    
___ answer3609476 ___

Es könnte sein:

  • Ablaufzeitpunkt
  • Jede Art von Eingabe (Benutzer, Datei, Netzwerk usw.)
___ qstnhdr ___ Quellen des Nicht-Determinismus ___ answer3609481 ___

Auf verschiedene Arten:

  • Verwenden Sie mehrere Threads auf eine Weise, die ein Datenrennen beinhaltet
  • verwendet die aktuelle Systemzeit als Eingabe,
  • mit nicht initialisierten Variablen,
  • ...

Wir können sicherlich mehr Vermutungen anstellen, aber wenn Sie sinnvolle Hilfe erhalten möchten, wäre es vielleicht gut für Sie, die relevanten Teile Ihres Codes zu veröffentlichen: -)

    
___ answer3609722 ___

Wenn Ihre Ausgabe von einer Adresse abhängt, die auf dem Heap zugewiesen ist:

%Vor%

Bei jedem Lauf kann malloc () eine andere virtuelle Adresse zurückgeben - ganz zu schweigen von NULL, falls die Zuweisung fehlgeschlagen ist.

    
___ answer3610535 ___
  

Neben einem stray Aufruf an rand ()

%code% ist vollständig deterministisch, solange Sie ihm den gleichen Anfangswert geben.

    
___ answer3610466 ___

Die Verwendung des Werts eines Zeigers anstelle dessen, worauf er zeigt, führt immer zu interessanten Ergebnissen.

    
___ answer3609484 ___

Ohne etwas Code zu sehen (TIPP HINZUFÜGEN), würde ich am besten nach einem Muster suchen. Vielleicht etwas Datum-Zeit-spezifische.

Versuchen Sie auch, nach Rennbedingungen zu suchen. Das kann nicht-deterministisch aussehen.

    
___ answer3616787 ___

Wenn Ihr Programm float / double verwendet, kann es zu Abweichungen im Ergebnis kommen, wenn in einer Architektur Kontextwechsel erfolgt.

Auf x86 verwendet die FPU eine erweiterte Genauigkeit für das Zwischenergebnis, aber wenn sie im Arbeitsspeicher gespeichert wird (was passiert, wenn ein Kontext entweder einen Prozess oder einen Thread wechselt), geht diese Genauigkeit verloren. Das könnte zu einer kleinen Abweichung des Ergebnisses führen (wir haben ein solches Problem in unserem Programm entdeckt). Eine Möglichkeit, dieses Problem zu vermeiden, besteht darin, den Compiler aufzufordern, nicht FPU, sondern SSE für Fließkommaoperationen zu verwenden.

Ссылка

    
___ answer3611463 ___
  • Eingaben von Netzwerk / Internet.
  • Datum / Uhrzeit
___ answer3611519 ___

In den Programmen, die nicht viel mit der "Außenwelt" interagieren, ist die populäre Quelle des Nicht-Determinismus die Abhängigkeit vom Zeigervergleich. Von Zeit zu Zeit sieht man es vielleicht im Code: Wenn eine lexikographische Vergleichsfunktion keine Vergleichswerte mehr hat (alles ist gleich), vergleicht sie die Adressen von Objekten als letzte Möglichkeit. Dies kann zu unterschiedlichen Ordnungen führen, wenn die Objekte im dynamischen Speicher zugeordnet werden, da die tatsächlichen Zuweisungsorte von Plattform zu Plattform und von Lauf zu Lauf unterschiedlich sein können.

    
___ answer3611442 ___

Offensichtlich eine neue Instanz des Mondphasen-Bugs .

    
___ answer3611670 ___

Sie haben nicht viele Informationen gegeben. Jedoch, als jemand, der Echtzeit-Programmierung für einen Lebensunterhalt macht, die wahrscheinlichsten Schuldigen, die ich suche, wenn solche Dinge passieren, ist:

  • Uninitialisierten Speicher verwenden.
  • Eine Race-Bedingung.
  • Eine obskure Kombination der obigen.

Zum Beispiel gab es einen solchen Fehler, bei dem ich einmal davon ausgegangen war, dass die gemeinsam genutzte Bibliothek nicht so "geteilt" war, wie ich dachte, und einen Griff aus einem Prozess zu verwenden, um eine Tabelle zu initialisieren, die in einem zweiten Prozess noch nicht initialisiert war. Abhängig davon, wie die Dinge gestartet wurden, die wichtige Daten in einem dritten Prozess verursacht haben oder nicht, werden sie zerstört.

    
___ answer3611702 ___

Irgendein undefiniertes Verhalten. h. es werden Hunderte von Seiten benötigt, um jede mögliche Quelle der Veränderung der Ausgabe zu erklären. Versuchen Sie das Debuggen, um zu finden, wo eine Änderung auftritt, oder lesen Sie eine C ++ - Spezifikation.

    
___ tag123c ___ C ++ ist eine universelle Programmiersprache. Es wurde ursprünglich als Erweiterung von C entworfen und behält eine ähnliche Syntax, ist aber jetzt eine komplett andere Sprache. Verwenden Sie dieses Tag für Fragen zu Code, der mit einem C ++ - Compiler kompiliert werden soll. ___ tag123deterministic ___ Das System oder Programm weist in verschiedenen Läufen das gleiche Verhalten auf. ___ tag123heidenbug ___ Ein Softwarefehler, der verschwindet oder sein Verhalten ändert, wenn man versucht, ihn zu untersuchen, zu untersuchen oder zu isolieren. ___ tag123nondeterministic ___ Nichtdeterminismus bezieht sich entweder auf ein Computersystem, bei dem das Ergebnis eines von vielen spezifizierten Ergebnissen sein kann, oder auf ein theoretisches Konstrukt, bei dem ein Computersystem viele Optionen parallel ausprobieren kann, um nach einem Ergebnis zu suchen. ___ tag123random ___ Dieses Tag ist für Fragen gedacht, die sich auf Zufallszahlen und deren Generatoren beziehen, sei es pseudozufällig oder wirklich zufällig. ___
1
Antwort

Seltsames Verhalten von C # im Debugger gegenüber der normalen Ausführung hat einen Heisenbug verursacht

Ich habe gerade die letzte Stunde damit verbracht, ein bizarres Problem mit nicht verwaltetem Speicher in C # anzugehen. Zuerst ein bisschen Kontext. Ich habe eine C # -DLL, die einige native Methoden (via diese tolle Projektvorlage ) export...
03.10.2012, 10:34
12
Antworten

Quellen des Nicht-Determinismus

Mein angeblich deterministisches Programm erzeugt eine von ein paar leicht unterschiedlichen Ausgaben in verschiedenen Läufen. Die Eingabe, der Compiler und der Computer sind unverändert. Ich bin mir nicht sicher, welche Ausgabe richtig ist, wei...
31.08.2010, 13:29