Problem mit Threads unter Windows
-
Was hat den ein Segmentationfault mit nem deadlock zu tun?
Starte das Programm mit dem Debugger und schau wo der Segmentationfault auftritt.
-
Das habe ich bereits geschrieben: #0 0x08214dd0 in ?? ()
Mehr gibt's nicht!
-
Das ist irgendeine Adresse.
Wenn du Debuggst dann siehst du die stelle im Code, wo der Fehler auftritt.
-
Das ist der Stacktrace und der zeigt afaik auf, wo der Fehler aufgetreten ist. Ansonsten nenne mir doch bitte einen anderen Debugger Befehl. Nochmal: es handelt sich hierbei um Code, der unter Linux fehlerfrei funktioniert. Nur unter Windows kommt es in dem Moment, in dem die Threads aktiviert werden zu besagtem Fehler und ich will wissen, wie ich das unter Windows umgehen kann, wofür ich auch den Auszug aus der boost Referenz verlinkt habe!
-
der tip mit dem debugger ist der einzig richtige. erstens weiss kein mensch, wie dein code aussieht und zweitens wirst du mit einem venünftigen source-level debugger (z.b. der von visual studio) dem fehler selber schnell auf die schliche kommen.
-
Ich hab keine Ahnung, wie ich da ran gehen soll. Ich weiß, dass
thread = Glib::Thread::create (sigc::mem_fun (*streams [0], &recorder::monitor), false);den Fehler auslöst. Aber ich weiß nicht warum! Unter Linux funktioniert es auch und eigentlich sollte sich die Threads einer plattformunabhängigen Bibliothek wie glibmm unter Windows genauso verhalten. Als Debugger steht mir nur der gdb zur Verfügung. Ich habe keine Ahnung, wie ich das debuggen soll und ich weiß zu wenig über die Arbeitsweise von Windows um zu erahnen, was den Fehler evtl. ausmachen könnte!
Danke für alle Hinweise
-
Besorg dir für Windows Visual C++ 2005 Express oder 2008 Express, die haben einen sehr sehr guten Debugger dabei.
Ansonsten: der Abschnitt aus der Boost.Thread Doku den du verlinkt hast, da gehts nur um Fälle wo in der Initialisierungsphase (also bevor main() läuft) schon Threads erzeugt werden. Das musst du eben vermeiden.
-
Was bringt einem so eine Adresse wie 0x08214dd0 beim debuggen?
-
basti33 schrieb:
Ich hab keine Ahnung, wie ich da ran gehen soll.
Programmm im Debugger-Modus starten, Fehler erzeugen, anschauen was genau da passiert.
basti33 schrieb:
Unter Linux funktioniert es auch und eigentlich sollte sich die Threads einer plattformunabhängigen Bibliothek wie glibmm unter Windows genauso verhalten.
Einer der großen Denkfehler (angehender) Programmierer ist es zu glauben, ein "nicht abstürzen" sei das gleiche wie "funktioniert". Das ist aber nicht der Fall. Möglicherweise ist Dein Code grundsätzlich falsch, aber auf Grund eines Zufalls/Nebeneffekts stürzt das unter Linux nicht ab. Stichwort: Programming by accident
basti33 schrieb:
Ich habe keine Ahnung, wie ich das debuggen soll und ich weiß zu wenig über die Arbeitsweise von Windows um zu erahnen, was den Fehler evtl. ausmachen könnte!
UNd ebenso haben Wir keine Ahnung wie Dein Sourcecode aussieht, daher ist es faktisch unmöglich Dir zu sagen was Du falsch machst.
-
Debug Interessierter schrieb:
Was bringt einem so eine Adresse wie 0x08214dd0 beim debuggen?
die adresse allein? --> nichts!
