wxSocketServer stirbt nach 24h/am nächsten Tag?

MaDsTyLe

Hallo allerseits,

ich habe ein eigenartiges Problem und würde mich freuen, wenn Ihr einfach mal Ideen und Vermutungen äußern könntet, weil ich echt keine Ahnung habe, welcher Quelltext-Ausschnitt dafür verantwortlich ist.

Ich habe mit wxAppConsole eine Server-Applikation entwickelt, welche auf einem Linux-root (Debian) läuft. Ausschließlich TCP-Verbindungen.

Die Clients sind für Windows programmiert und haben sich nach dem Verbindungsaufbau beim Server anzumelden, dh. Daten zu senden.

Eigentlich funktionieren Server und Clients tadellos, aber nach geraumer Zeit passiert folgendes:

Ich starte meinen Client -> der Server erkennt die neue Verbindung -> mein Client schickt die von mir eingegebenen Anmelde-Daten an den Server -> der Server stürzt ohne weitere Meldung SOFORT ab.

Ich habe den Absturz mehrfach reproduziert, und zwar passiert es immer erst, wenn sich für lange Zeit kein Client mehr verbunden/angemeldet hat.
Beispielsweise, wie im Titel beschrieben, am nächsten Tag.

Ich habe versucht eventuelle Fehlermeldungen zu speichern indem ich screen eine log-Datei produzieren ließ, die alle Ausgaben an stdout und stderr schrieb.
Keine Fehlermeldung - kein "segmentation fault" ("Speicherzugriffsfehler") - nichts.

Wenn Ihr irgendeine Idee habt, wie ich weiter vorgehen kann, würde mich das sehr glücklich machen.

Ich danke bereits hier allen, die sich Gedanken zu diesem Absturz machen.

Viele Grüße,
Max

player424

Du könntest den Server mal mit Debuginformationen übersetzen und im Debugger laufen lassen. Dann weisst du zumindest schon einaml warum der Server abstürzt, und evt. auch die Stelle an der es "kracht".

MaDsTyLe

Hallo player424,

danke für Deine Antwort - wie debugge ich unter Linux?

Viele Grüße,
Max

player424

Benutze am besten den gdb (GNU Debugger). Der wird über die Kommandozeile bedient, aber es gibt auch grafische Frontends dafür. Google einfach dann findest du genug. Eins davon ist z.B. ddd .

P.S. Beim gcc den -g Schalter nicht vergessen

MaDsTyLe

Ok, installiert ist er und kompiliert hab ich jetzt mit -g.

Aber wie debugge ich damit jetzt am besten?
Ein BreakPoint wird doch wohl nicht viel helfen, oder?

Viele Grüße,
Max

break main

step - wenn du in funktionen reinspringen willst
next - nächste zeile
print(expression) - wobei expression hier alles sein darf: *ptr dereferenziert den ptr und bekommt den wert. oder print(stdString.c_str()) geht auch.

MaDsTyLe

Ok, das hier hat heute der Debugger ausgespruckt:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000409836 in wxNodeBase::GetData (this=0x0)
    at /home/Server/wx/include/wx-2.9/wx/list.h:451
451         void *GetData() const { return m_data; }

Was sagt mir das jetzt?
Warum tritt das Problem erst nach längerer Zeit ein?

Ideen?

Viele Grüße,
Max

MaDsTyLe schrieb:

Ok, das hier hat heute der Debugger ausgespruckt:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000409836 in wxNodeBase::GetData (this=0x0)
    at /home/Server/wx/include/wx-2.9/wx/list.h:451
451         void *GetData() const { return m_data; }

Was sagt mir das jetzt?

Dass man sich auf eine Gefrickel-Lib wie wxWidgets nicht einlassen sollte.

MaDsTyLe

Hey TheTruth!, danke für Deinen Beitrag.

Er bringt mich zwar nicht direkt weiter, aber dennoch habe ich das Gefühl, dass Du Recht haben kannst und der Fehler nicht in meinem Code, sondern im wxCode steckt.

Ich werde das Ganze jetzt mal mit den neuen wx-Sources kompilieren und schauen, ob der Fehler weiterhin auftritt.

Viele Grüße,
Max

phlox81

Zeig doch mal was code...
Das da nen null Pointer rumfliegt muss nicht die Schuld von wx sein.
Auch wenn ich Server heute eher mit boost::asio schreiben würde als mit wxWidgets...

player424

phlox81 schrieb:

Zeig doch mal was code...
Das da nen null Pointer rumfliegt

Wo steht was von nem Null-Pointer 0o

MaDsTyLe

Leute, ich könnte heulen, das kanns echt nicht sein

Ich habe die Server-Applikation vollständig neu geschrieben, ohne wxWidgets, sondern mittels Poco.

Und gerade eben mache ich den "Langzeit"-Test.
Heute in der Nacht gestartet -> mit Client verbunden -> tadellos
Vor fünf Minuten mit Client verbunden -> Verbindung kommt zustande -> Client sendet die ersten Daten -> momentaner Absturz der Server-Applikation

Ich begreife das einfach nicht und ich habe das Gefühl, dass das Problem weder in wxWidgets noch in Poco noch in meinem Code zu finden ist, sondern ein Problem meines root-Servers ist, der vielleicht meinen Socket nach einiger Zeit irgendwie verändert ...

Das blöde (fürs Problem) ist, dass alle anderen Netzwerk-Dienste ja anstandslos laufen (Apache2, FTP, SSH, ... , TeamSpeak2, ...).

Was kann denn das sein?

Kann das mit screen zu tun haben? Ich denke nicht.

Habt Ihr irgendwelche Ideen, die mich eventuell weiterbringen?

Ich habe echt keinen Schimmer, was das soll und wie ich mir helfen kann ...

LG Max

phlox81

player424 schrieb:

phlox81 schrieb:

Zeig doch mal was code...
Das da nen null Pointer rumfliegt

Wo steht was von nem Null-Pointer 0o

this 0x0 deutet darauf hin. Genaues kann man aus dem kleinen Ausschnitt aber auch nicht erraten.

@MaDsTyLe
Ohne Code kann dir da niemand helfen, evtl. ist ja der selbe Fehler in beiden codes.
Ansonsten, ja kann sein, das der Fehler in der Config deines Servers liegt.
Oder ist es evtl. der 24h disconnect deines Providers?

MaDsTyLe

Oh man, ich glaub ich hab des Teufels Hörner erwischt; gerade überlege ich, welche Klassen ich Euch darlege und schließe meine MySQL-Schnittstelle (Wrapper der MySQL-C-API) in Gedanken schonmal aus.

Das wird es sein! Die Verbindung zur MySQL(5)-Datenbank nehme ich nur beim Programmstart einmal auf! Sobald der Client seine (Zugangs-)Daten sendet, werden diese mit denen aus der Datenbank (mysql_query(), mysql_num_rows(), mysql_fetch_row()) abgeglichen.
Der MySQL-Server wird wohl ein Timeout für die Sitzungen haben und dieses muss ich bemerken und die Verbindung neu aufnehmen lassen.

mysql_query() scheint CR_SERVER_GONE_ERROR zurückzugeben, sobald die Verbindung beendet wurde.

Das werde ich abfragen und einen Reconnect einleiten.

Mein Gott und ich Holzkopf schreibe den ganzen Kram neu.

Weiß denn jemand zufällig, wie das aussieht mit dem (Standard-)Timeout bei einer MySQL(5)-Verbindung?

LG Max

PS: Aber auch interessant zu wissen, das meine MySQL-Schnittstelle einen Speicherzugriffsfehler produziert, sobald die Verbindung tot ist - nicht so ganz optimal

PS2: Ok, ich weiß jetzt auch, nach welcher Zeit die MySQL-Verbindung abgebrochen wird. Unter Linux ganz einfach mysqladmin -uBENUTZERNAME -pPASSWORT variables eingeben (mit jedem Benutzer möglich) und schon werden die Systemparameter ausgespuckt und ganz unten in der Liste findet sich der Eintrag "wait_timeout", welcher bei mir den Wert 28800 (Sekunden) hat.
Teilt man das nun zweimal durch 60s bzw. einmal durch 3600s, so ergeben sich 8h.
Gelöst!