Rolf B: Umgang mit zerstörter Session

Beitrag lesen

Hallo Raketenwilli,

Jetzt muss man nur noch herausfinden, was bei Dir von wem in das Session-File geschrieben wird.

Die einzige Sessionmanipulation ist Lesen und Schreiben von $_SESSION-Einträgen. Da kommen Zahlen, Strings, Objekte und Arrays rein, was halt so nötig ist, um den Spielerfortschritt festzuhalten und bei einer Schlägerei die Gesundheit der Gegner zu tracken. Das Sessionfile wird vom PHP files Sessionmanager gelesen und geschrieben, da mach ich selbst nichts dran.

Natürlich kann Unicode in der Session landen, als Teil eines Strings. Aber das ist eigentlich kein Problem.

Kann ich mal sehen, was Dein Skript so treibt?

Sind bereits einige 100 Zeilen Krimskrams. Ein Browserspielchen, zum Spaß (ich möchte ein Abenteuerspielebuch abbilden). Den Source poste ich jetzt eher nicht 😉. Wärest Du noch registriert, könnte ich Dir eine Post schicken. So schick ich Dir jetzt eine Mail an deine Kontaktadresse bei f…x.org

Es kann höchstens sein, dass PHP die Session nicht sauber geschlossen hat und dann, als ich ein paar Stunden weg war, der IIS den FastCGI Prozess beendet hat, so dass die Datei nur teilweise gespeichert wurde. Das wäre dann ein PHP Bug, es sollte auch bei fatal errors die Session am Ende des Scripts immer committen und die Datei freigeben. Ein File Lock auf die Datei sollte es nur geben, solange der Request läuft.

Ohne die Datei zu editieren (ein deutlich anormaler Usecase) bekomme ich den Fehler nicht mehr reproduziert. Aber ich kann ihn jetzt triggern und einen sauberen Restart ausführen.

Rolf

--
sumpsi - posui - obstruxi