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

Schon mal nen debugger benutzt?

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...

Starte das Programm mit dem Debugger und schau wo der Segmentationfault auftritt.

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

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.

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.

Was bringt einem so eine Adresse wie 0x08214dd0 beim debuggen?

die adresse allein? --> nichts!