Webserver stürzt ab
-
Hi leute,
ich bin grad dabei nen Webserver unter Linux zu programmieren.
Das Problem ist: Wenn ich bei Google Chrome auf der F5 lange drauf bleibe, werden so viele Anfragen an den Serer gesendet, das dieser Abstürzt. Wenn ich allerdings mit ApacheBench oder LOIC meinen Webserver benchmarke stürzt er nicht ab. Es kommt auch keine Fehlermeldung, wie z.B. Segmentation fault.
Kann mir jemand sagen, wie ich herausfinden kann, warum er abstürzt?
Hoffe auf gute Antworten
-
Debugger.
-
gdb schrieb:
Debugger.
Aber mit Debuggern kann ich doch nur durch das Programm durchsteppen. Wie soll ich das machen, wenn so viele Anfragen kommen?
-
DerDebugger schrieb:
gdb schrieb:
Debugger.
Aber mit Debuggern kann ich doch nur durch das Programm durchsteppen. Wie soll ich das machen, wenn so viele Anfragen kommen?
Ein Debugger kann dir anzeigen warum das Programm abstürzt und wo ungefähr. Da musst du nicht steppen.
Du benutzt vermutlich C oder so. Dafür könntest du gdb nehmen. Valgrind kann auch hilfreich sein.
-
TyRoXx schrieb:
DerDebugger schrieb:
gdb schrieb:
Debugger.
Aber mit Debuggern kann ich doch nur durch das Programm durchsteppen. Wie soll ich das machen, wenn so viele Anfragen kommen?
Ein Debugger kann dir anzeigen warum das Programm abstürzt und wo ungefähr. Da musst du nicht steppen.
Du benutzt vermutlich C oder so. Dafür könntest du gdb nehmen. Valgrind kann auch hilfreich sein.Kenn mich mit Debuggern nicht so gut aus. Ja, das Programm ist in C geschrieben.
Also kann ich das Programm unter einem Debugger ausführen und wenn es abstürzt kommt dann eine Meldung oder muss ich dann von Hand den Dpeicher untersuchen oder so?
-
Da musst du dir wohl die Mühe machen: ein Tracing auf stderr mittels __FILE__, __LINE__, __func__ (C99), __FUNCTION__ (GCC) ?!
Evtl. auch assert zusätzlich.
-
Wutz schrieb:
Da musst du dir wohl die Mühe machen: ein Tracing auf stderr mittels __FILE__, __LINE__, __func__ (C99), __FUNCTION__ (GCC) ?!
Was meinst du mit "_File_ _Line_..."?
-
Ein Programm, welches abstürzt erzeugt unter Unix und Linux normalerweise eine core-Datei. Die kann man sich mit einem Debugger anschauen. Insbesondere ist der Stacktrace hilfreich.
Bei Linux sind die core-Dateien häufig deaktiviert. Man kann sie aber auch aktivieren.
Wenn Du das Programm direkt aus dem Debugger aufrufst, bleibt der Debugger beim Absturz genau da stehen, wo der Absturz passiert. Das ist natürlich das einfachste.
-
Nur weil ich den Beitrag gerade lese: Falls dein Programm nicht mit Dump abstürzt sonder scheinbar nur beendet wird, hast du wahrscheinlich send() aufgerufen, während der socket von der anderen Seite geschlossen wurde. Das führt in Linux zum Signal SIGPIPE, wenn du es nicht abfängst und beendet einfach den Prozess.
SIGPIPE kommt mir nämlich regelmäßig beim Portieren in die Quere.
Und mehrfache Browser-Refreshes schließen Sockets gerne mal ohne eine Antwort abgewartet zu haben.
-
xor schrieb:
Nur weil ich den Beitrag gerade lese: Falls dein Programm nicht mit Dump abstürzt sonder scheinbar nur beendet wird, hast du wahrscheinlich send() aufgerufen, während der socket von der anderen Seite geschlossen wurde. Das führt in Linux zum Signal SIGPIPE, wenn du es nicht abfängst und beendet einfach den Prozess.
SIGPIPE kommt mir nämlich regelmäßig beim Portieren in die Quere.Und mehrfache Browser-Refreshes schließen Sockets gerne mal ohne eine Antwort abgewartet zu haben.
Omg du bist ein Held. Es funktioniert
Ich habe jetzt anstatt "send(sockfd, ptr, size, 0)" "send(sockfd, ptr, size, MSG_NOSIGNAL" geschrieben und es funktioniert
Du glaubst nicht wie dankbar ich dir bin
-
Freut mich
Es ist schon furchtbar, dass unter POSIX fast jede System-Funktion mit EINTR unterbrochen werden kann und manche Funktionen anstatt eines Return-Codes dann in einem Signal-Handler landen, der per default exit() ausführt. Was ein "schwerer" Fehler ist oder nur so eine seltsame Angewohnt find ich da schon etwas undurchsichtig, aber ist halt so
