Problem mit Threads unter Windows
-
Hallo,
ich schreibe eine gtkmm Applikation unter der ich Threads verwenden möchte. Die Threads (es werden beliebig viele) werden von der Klasse Threads verwaltet, in der beliebig viele Objekte einer anderen Klasse erzeugt werden. Deren Methoden werden den Threads übergeben. Gestartet wird das ganze durch das main_window (meine gtkmm Klasse). Zunächst habe ich thread_group aus der boost Bibliothek verwendet. Unter Linux funktionierte dies fehlerfrei. Unter Windows kam es jedoch zu einem Segmentation fault, sobald ich die Threads gestartet habe. Ein backtrace gab folgendes zurück: #0 0x08214dd0 in ?? (). Daraufhin habe ich einen neuen Versuch mit den Threads aus der glibmm Bibliothek gestartet. Auch hier funktioniert es unter Linux wieder fehlerfrei, wohingegen es unter Windows zu dem gleichen Fehler kam. In der Boost::Thread Dokumentation habe ich diesen Abschnitt gefunden, der das Problem vermutlich erklärt. Allerdings weiß ich momentan nicht, wie sich die hier aufgeführten Fehlerquellen umgehen lassen. Trifft Punkt 2 auf meine gtkmm Klasse zu? Ich weiß leider nicht, was ich mir unter einem "global static object" vorstellen soll.
Kann mir hier irgendjemand weiterhelfen?Danke
-
In der Fehlerbeschreibung gehts doch um nen deadlock, was willst du damit
Schon mal nen debugger benutzt?
-
<yxcvbnm schrieb:
In der Fehlerbeschreibung gehts doch um nen deadlock, was willst du damit
Was soll ich denn damit "wollen"? Ich will Ratschläge, wie sich dieses Problem umgehen lässt.
<yxcvbnm schrieb:
Schon mal nen debugger benutzt?
Durchaus, allerdings weiß ich leider momentan auch nicht, wie mir der jetzt weiterhelfen soll...
-
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!
