PureBoard

Ich habe mal ein paar Sachen behoben, verbessert und aufgeräumt. Dabei war nichts wo ich sicher wäre, dass es deinen Absturz verursacht, aber einen Versuch ist es trotzdem wert.

Es gab in alten Version ein Speicherleck beim Lesen des HTTP Headers, je nach größe des gesendeten Headers wurden so vielfache von 2048 Bytes nicht wieder freigegeben. Außerdem werden jetzt alle Speicherallokationen überprüft, damit ist auch eine Fehlerquelle (Für seltsame Fehler wo der Debugger keine hilfreichen Informationen mehr rausrückt) beseitigt. Daneben hab ich noch eine mögliche Race condition und eine möglichkeit Deadlocks zu erzeugen behoben, aber die sind bei dir eher nicht aufgetreten und hätten sich anders geäußert.

https://github.com/Dadido3/WebSocket_Server/releases

Du bist super!!!
Gleich mal testen

Ach was mir einfällt:
Ich arbeite ja nicht mit Threads. Ich benutze dein "Polling".

Also: Können da vielleicht die "Fehler" entstehen?

Das mit dem Polling ist schon korrekt. Auf die Weise wird eben sichergestellt, dass das Event-Callback in dem selben Thread läuft wie dein anderer Code. Und dadurch musst du dich nicht mit Threads herumschlagen. Eventuell könnte noch ein Fehler bei dir in der Handhabung der Events sein, aber ich hatte ja letztes mal schon Quer über den Code geschaut, und mir ist nichts aufgefallen.

Trotzdem, kannst du mir nochmal sagen, welche Zeilennummer genau den Fehler verursacht hat (Oder mir die umliegenden Zeilen drumherum nennen).

Zeile 811
Da meckert die Ide, ich weiss nicht mehr genau welche Meldung, entweder Speicherfehler oder Objekt gibt es nicht.
Aber wie schon gesagt, sehr sehr selten.

Ok,

• *Object existiert auf jeden Fall, außer du rufst eine Serverfunktion auf nachdem der Server von dir geschlossen wurde. Das ist aber hier nicht der fall.
• Genauso existiert die Liste *Object\Client() bis der Server vom Benutzer beendet wird.
• Die Objekte innerhalb der Liste oder die Listenposition werden/wird nicht gleichzeitig an anderer Stelle geändert, es ist durch einen Mutex abgesichert.

Wahrscheinlich passiert irgendo vorher ein illegaler Speicherzugriff und das was der Debugger zurück gibt ist nur die Spätfolge davon. Sag bescheid wenn es wieder Probleme gibt, eventuell auch mal auf den Speicherverbrauch achten, ob der mit der Zeit immer mehr ansteigt.

Eventuell kann ich ja nochmal nen Blick über den kompletten Code werfen, wenn es dir nichts ausmacht.

Alles klar.
Ich baue meinen Serverprogramm gerade um, wenn ich fertig bin, kann ich dir gerne den Code geben.
Ich kann aber jetzt schon sagen, dass ich niemals einen Client absichtlich beende, sondern immer nur auf beendete Clients reagiere.
Erst einmal besten Dank für alles!
Ich melde mich!

Ich habe das Modul mal mit Hilfe der Autobahn|Testsuite testen lassen. Dabei habe ich noch einige sachen behoben, das betrifft aber eher die Konformität mit dem WebSocket Standard. Außerdem unterstützt der Server nun das Zusammenfassen von fragmentierten Frames, was aber optional ist (opt-out) falls der Nutzer des Moduls bzw. die Applikation das nicht bereits übernimmt.

Damit, und mit ein paar anderen Änderungen ist der Server nun wirklich kompatibel mit dem WebSocket standard. Das heisst nicht, dass er nun alles unterstützt. Zum Beispiel gibt es keine Datenkompression und WebSocket extensions werden auch nicht unterstützt. Aber er sollte jetzt mit allen Client-Implementationen zusammenarbeiten, da eh nur die Features ausgehandelt werden, welche von beiden Seiten supportet werden.

Die aktuell(st)e Version ist >hier< zu finden.

@stevie1401

Du kannst ja erstmal noch mit der alten Version (v1.003) weiter testen. Falls du dann nach einiger Zeit mit ziemlicher Sicherheit sagen kannst, dass es keine Probleme mehr gibt, kannst du, wenn du willst, auf die neue Version wechseln.

Ich habe deinen Text leider erst eben gelesen, denn ich wollte gerade etwas zur Version 1003 schreiben:

Heute ist mein Purebasic-Webserver erneut 2x kurz hintereinander wortlos abgestürzt.
Er lief in der Linux IDE, die es wieder nicht bemerkte.
Es waren ca 80 Clients dran und da der "laufende Betrieb" reibungslos läuft, vermute ich inzwischen, dass es mit der Anmeldung an den Server oder mit der Abmeldung vom Server zu tun haben muss.
Vielleicht ein "unüblicher" Browser?
Kann man sich vor diesem "schützen" bzw. dafür sorgen, dass sich dieser gar nicht erst anmeldet?
Ab morgen läuft der Server eine Zeit lang in einer Windows IDE. Vielleicht gibt das mehr Information.

Ich teste jetzt mal die 1004-Version. Unter Windows. Kann ja sein, dass die Linux IDE auch etwas fehlerhaft ist und nicht alle Fehler erkennen kann.

Ich bin leider etwas ratlos.

Ich habe die letzten Tage einen Test-client geschrieben, welcher den Server mit Nachrichten und Verbindungsanfragen bomardiert. Auch habe ich den Server dahin optimiert, sodass er in der Lage ist viel mehr Anfragen und Pakete zu verarbeiten.

Gestern hatte ich es dann geschafft mit dem Testaufbau nach ungefähr einer halben Stunde einen "Speicheroverflow" zu provozieren. Leider hat sich dann heute rausgestellt, dass es sehr wahrscheinlich ein Bug in PureBasic ist (In Kombination von Purifier + ReAllocateMemory + Multithreading). "Leider" deshalb, weil der Bug meiner Meinung nach zu keinem Absturz führt, und nur Fehlmeldungen des Purifiers verursacht. Somit ist der Fehler immer noch nicht behoben.

stevie1401 hat geschrieben:Vielleicht ein "unüblicher" Browser?

Wenn du rausfinden könntest, ob da irgendwo ein Zusammenhang besteht, könnte ich eventuell in diese Richtung weitersuchen. Dazu könntest du in eine Logdatei schreiben, wer sich wann verbindet und wer wann die Verbindung trennt. Aber ich glaube nicht, dass es an einem Client liegt.

stevie1401 hat geschrieben:Kann man sich vor diesem "schützen" bzw. dafür sorgen, dass sich dieser gar nicht erst anmeldet?

Im Idealfall gibt es keinen Browser oder Client, welcher Abstürze verursacht. Und falls doch, dann würde ich eher das grundlegende Problem beheben.

stevie1401 hat geschrieben:Kann ja sein, dass die Linux IDE auch etwas fehlerhaft ist und nicht alle Fehler erkennen kann.

Die IDE und der Debugger von PureBasic sind generell etwas überfordert (bzw. komplett unbrauchbar), wenn Multithreading im Spiel ist. Ich glaube ich werde für dich eine Version erstellen, welche komplett auf Threading verzichtet. Das kann im schlimmsten Fall dafür sorgen, dass das Problem verschwindet. Und im besten Fall liefert der Debugger endlich mal korrekte Fehlermeldungen, die weiterhelfen. Letzterer Fall wäre mir am liebsten, da ich dann das Problem eingrenzen kann (Egal, ob das Problem letztendlich in meinem Code liegt, oder in PureBasic).

Ich erstelle heute abend noch die komplett "threadlose" Version vom Server. Wäre schön, wenn du die dann nächstmöglichst verwendest, und den Server dann wie jetzt auch im Debugger laufen lässt. Ich verlinke die dann hier.