Sporadischer "Segmentation Fault"

[solarix]

jedoch wird der Konstruktor [...] erreicht, aber läuft nicht bis zum Ende durch. Hab da mal durch zwei Debug Ausgaben am Anfang und Ende getestet.

Wenn dein Code-Schnipsel stimmt (also nicht reduziert gepostet wurde) und davon ausgehend, dass Trolltechs "setSocketDescriptor" nicht abserbelt, kann der Konstruktur kein Segfault schmeissen (keine Pointer). Denk aber daran, dass bei Multithreading-Applikationen auch ein parallel arbeitender Thread crashen kann... Egal, wo sich die anderen Threads befinden (z.B. in einem Konstruktor).

mit dem Debugger habe ich nicht geschaut da der Fehler nicht reproduzierbar ist

Ich gehe davon aus, dass du unter Linux arbeitest ("SegFault"). Auf Unix-Systemen kannst du core-dumps erstellen lassen, welche du nach dem Crash analysieren kannst. Gängige Distributionen schalten diese jedoch ab.. gehe also wie folgt vor (z.B. Debian):
1. $ sudo ulimit -c unlimited
2. Programm (Debug-Version) starten
3. Programm crashed (File "core" wird von OS erzeugt)
4. Stack analysieren mit gdb: $ gdb programm core
Der Debugger gdb lädt dein Programm zusammen mit der Core-File. Mit dem Kommando "where" printet gdb den Programm-Stack aus (und damit die exakte Stelle, wo das Programm crashed).

[Viper2000]

@Christian81: ja so kann ich das Umbauen! Jetzt weiß ich auch so in etwa worauf du hinaus wolltest.
Sollte ich die connects dann
"Qt::QueuedConnection"
machen oder lieber
Qt::DirectConnection

klar, wenn ich es Queued mache dann wartet die eventloop solange bis sie den Slot bedienen kann. Aber in meinem Fall sollte es doch egal sein!? Verstehe den Unterschied in meinem Fall nicht. Denn im Prinzip will ich ja erstma nur das Signal "readyRead()" des Sockets mit meinem eigenen Slot "readData()" verbinden

In der Thread Doku steht ja:

With auto connections (the default), the behavior is the same as with direct connections if the signal is emitted in the thread where the receiver lives; otherwise, the behavior is that of a queued connection.

Also sollte das doch reichen!?

@Solarix: Danke für die Ausführliche Schilderung. Werde dann mal mit dem Dump auf Fehlersuche gehen.

[Christian81]

Die autp-connection greift aber nur beim Aufruf des connect() - und da gibt es ja bei Dir noch keinen Thread / leben beide Objekte im Main-thread.

[Viper2000]

Da das Signal, wenn ich alles nach deinen Vorschlägen umgebaut habe, aus dem gleichen Thread ist wie der Slot gebe ich also dann beim connecten als 5tes Argument
Qt::DirectConnection
mit damit der Slot auch wirklich in diesem Thread ausgeführt wird richtig !?

Gruß, viper

[Christian81]

Wenn Du es nach run() verschoben hast, ist es natürlich nicht mehr nötig. Ich habe mich aber auf dein Code-Schnipsel bezogen da ich nicht weiß wie du es atm hast.

[Viper2000]

Aso, ja ich werde es morgen nach den bisherigen Besprechungen hier im Forum umbauen. Werde dann in der Header im Private Bereich einen

QTcpSocket *mTcpSocket;

eintragen und dann mit new() in der run-Methode des Threads erzeugen. Danach dann direkt die Connects machen. In diesem Falle kann ich ja dann Autoconnect nutzen.

Werde dann Berichten ob es funktioniert hat.

Gruß, viper

[Viper2000]

So, habs mal umgebaut.
Habe in der Threadklasse noch eine public Methode "sendData()". Die Forderung ist, dass diese auch aus dem GuI-(Mainthread) aus aufgerufen werden soll. Sobald ich an die Stelle im Code (in der sendData()-Methode) komme wo ich ein mTcpScket->write(); ausführe, so kommt die Fehlermeldung:

Code: Alles auswählen

QObject: Cannot create children for a parent that is in a different thread.
(Parent is QNativeSocketEngine(0x809ec10), parent's thread is RF_Network_Server_ClientThread(0x80a3560), current thread is QThread(0x8055740)

Soweit klar, da ich diese sendData() Methode aus dem GuI Thread aus aufrufe. Damit wird das "mTcpSocket->write()" auch im GuI Thread gemacht und es führt zu der Fehlermeldung.
Die Frage ist nur wie ich dieses Problem am elegantesten lösen kann...das schreiben auf den socket soll auf jeden Fall auch im extra Thread ablaufen. Wäre für Erfahrungen mit solchen Problemen Dankbar!

Gruß, Viper