Multithreading Problem
-
ich gebe zu thread debugging isdt nicht das einfachste, aber fang doch bitte einfach mal ein mit printf() oder cout zu arbeiten. übergebe dem tread einen eindeutigen identifizierer damit du debugausgaben mit printf() gezielt steuern kannst. prüfe wo es tatsächlich kracht. kommentare und printf() sind die einfachsten debughilfsmittel
anhand dieses codes jedenfalls kann man nur mutmaßen, ich tippe sogar eher auf bugs ausserhalb dieses codes.
-
Wobei man auf den Inhalt der Ausgaben mit printf und cout nicht zuviel geben sollte. Wenn mehrere Threads gleichzeitig darauf zugreifen wird's Buchstabensuppe
-
It0101 schrieb:
Wobei man auf den Inhalt der Ausgaben mit printf und cout nicht zuviel geben sollte. Wenn mehrere Threads gleichzeitig darauf zugreifen wird's Buchstabensuppe
deswegen erwähnte ich ja eine möglichkeit wie man gezielt nur einen thread definieren kann, der debugausgaben macht
-
Hmm.. ich habe genug Ausgaben, die ich nur hier zur Vereinfachung herausgenommen habe. Laut gdb stürzt das Programm in der Zeile 44 ab. Aber irgendwie kann das nicht sein. Denn die entnommen Werte liegen im korrekten Bereich. Das Problem taucht eher mehr im mehrfachen Duchlaufen des Threadprogramms auf. Frage mich da eher, ob ich irgendein Speicherbereich nicht korrekt frei gemacht habe!
-
dann kommentier mal code aus... schritt für schritt... und probier ob es dann mit mehere thread funktioniert..
-
sothis_ schrieb:
ich gebe zu thread debugging isdt nicht das einfachste, aber fang doch bitte einfach mal ein mit printf() oder cout zu arbeiten.
Das nennt sich auch Shotgun Debugging und ist ein beliebtes AntiPattern.
@OP:
Da du anscheinend unter einen unixoidem BS arbeitest, versuch mal helgrind aus der Valgrind-Suite. Die anderen Tools wie z.B. memcheck können dir auch helfen Fehler zu finden, wenn Speicherzugriffsfehler vorkommen.Du solltest außerdem z.B. globale Variablen, übergebene Variablen etc., die von mehreren Threads gelesen werden und sich potenziell ändern können, mit volatile qualifizieren. Das hält den Compiler von gefährlichen Optimierungen (Annahmen über Unveränderbarkeit) im Multithreading Bereich ab.
-
Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable, wenn dann die Methode fehlerfrei durchläuft lockerst du den Zugriff Schritt für Schritt, ab da wo es den Fehler gibt weiß du ja welche Variable zuletzt freigegeben wurde, dann sperr den Zugriff auf alle bis auf diese und wenn es dann immernoch kracht hast du den Übeltäter gefunden.
-
Tippgeber schrieb:
Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable,[...]
Hiermit meine ich natürlich nur die Stack-Variablen die nicht an andere Methoden übergeben werden.
-
Tippgeber schrieb:
Tippgeber schrieb:
Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable,[...]
Hiermit meine ich natürlich nur die Stack-Variablen die nicht an andere Methoden übergeben werden.
Und für wie wahrscheinlich hältst du es, dass der Fehler nach Änderungen in der Synchronisierung noch auftritt
"Der Versuch verändert das Experiment"...
-
7H3 N4C3R schrieb:
Tippgeber schrieb:
Tippgeber schrieb:
Synchronisier doch zunächst einmal den Zugriff auf jede nicht-Stack-Variable,[...]
Hiermit meine ich natürlich nur die Stack-Variablen die nicht an andere Methoden übergeben werden.
Und für wie wahrscheinlich hältst du es, dass der Fehler nach Änderungen in der Synchronisierung noch auftritt
"Der Versuch verändert das Experiment"...
man passt die Umgebung Schrittweise wieder der alten an
-
idea schrieb:
man passt die Umgebung Schrittweise wieder der alten an Super Idee.
Und was ist, wenn das Problem nur in der ursprünglichlen Umgebung auftritt - wie es bei Multithreadingfehlern sehr häufig der Fall ist? Genau das ist Shotgun Debugging.
-
7H3 N4C3R schrieb:
idea schrieb:
man passt die Umgebung Schrittweise wieder der alten an Super Idee.
Und was ist, wenn das Problem nur in der ursprünglichlen Umgebung auftritt - wie es bei Multithreadingfehlern sehr häufig der Fall ist? Genau das ist Shotgun Debugging.Während du noch da sitzt und das Problem errätst haben andere das Problem mit ihrer Shotgutn längst erlegt
-
Oder glauben es, erledigt zu haben...
Hast du meinen Beitrag weiter oben gelesen? Race-Condition-Profiler? Verändert zwar auch das Experiment, aber nicht den ursprünglichen Code. Und zeigt dir auch artig mögliche Race-Conditions an, nicht nur tatsächlich aufgetretene. Und - ist ein systematisches und zielgerichtetes Vorgehen, anstatt wild, nach eigenem Gutdünken irgendwo Code einzustreuen, der den ursprünglichen Fehler vielleicht unauffindbar macht. Aber anscheinend bevorzugst du letztere Variante.
