Fehlermeldungen nach Update auf 2.5

Zitat von infected

... Ist ja lange genug gut gegangen. Prompt werde ich wieder mit ner schönen Meldung bestraft Ich werd gleich mal Beatinu´s Tipp testen.

Aber es kann sein, das die Performance deiner Blogs sehr leidet. Ich werd dann mal einen performanten Ersatz entwerfen und testen, kann aber etwas dauern, soll ja auch was halten :mrgreen:.

Getestet und für nicht gut befunden. Diese Änderung zerschießt mir z.B. die Übersetzung des Simple Forums.

Zitat von infected

Getestet und für nicht gut befunden. Diese Änderung zerschießt mir z.B. die Übersetzung des Simple Forums.

Schade. Was passiert genau?

Der Code deaktiviert alle Sprachdateien. Danach ist sowohl das Backend als auch alle Plugins mit language-files in Englisch. Das ergibt im Frontend einen Misch Masch aus Deutsch-Englisch. Fehlermeldungen konnte ich keine ausmachen

Zitat von Alphawolf

Schau dir mal den Call Stack an: http://www.zoosau.de/wp_error/

Hättest ja mal als Beigabe das hier noch geben können: #5599 (Sporadic timeout /wp-includes/gettext.php) - WordPress Trac - Trac
Die US Boys interessiert das seit 5 Monaten nicht, denn die brauchen ja kein Übersetzungsfile. Wenn wir uns also nicht selbst helfen, die werden es nicht machen. :cry:
Also ich zieh mir jetzt mal den Bereich gettext komplett rein und schau mir an, was das sein kann. Spannend ist die Aussage, dass die byteweise Ersatzroutine ein paar Übersetzungen schrottet, insbesondere wenn mehrere *.mo im Spiel sind (in dem Fall wohl das Simple Forum *.mo).

Erste Feststellung:

class StringReader {
  [COLOR=Red][B]var $_pos;[/B][/COLOR]
  var $_str;


  function StringReader($str='') {
    $this->_str = $str;
    $this->_pos = 0;
    [COLOR=Blue][B]echo "parent(init)<br />";[/B][/COLOR]
  }


  function read($bytes) {
[I][B][COLOR=Red]   [COLOR=Blue] var_dump($this->_pos);
    var_dump($this->_str);
    exit;[/COLOR][/COLOR][/B][/I]

Die _pos vom StringReader wird nicht initialisiert durch den CachedFileReader (parent Constructor nicht aufgerufen)! Die [COLOR=Blue]blaue[/COLOR] Ausgabe produziert nur folgendes:

NULL string(226673) "ޕ� ........

Alphawolf: Kann es sein, das in Stress-Situationen des Servers die _pos zufällige Werte annehmen kann, weil PHP die Klasse auf schon mal benutzten Speicher blendet, der irgendwie gefüllt ist? Dann liest man quasi Müll aus dem Binärstring und "seeked" sich u.U. tot bis die 30 Sekunden um sind.
Speziell wenn Bytecode Optimierer im Spiel sind, die cachen und bei vielen gleichzeitigen Zugriffen in mod_php den Bytecode nehmen und nochmal ausführen, kann es sein, das ich die letzte Inkrementierung eines anderen Benutzers bekomme, also ggf. mitten oder am Ende der Daten stehe ?

Zitat von codestyling

Die _pos vom StringReader wird nicht initialisiert durch den CachedFileReader (parent Constructor nicht aufgerufen)! Die [COLOR=Blue]blaue[/COLOR] Ausgabe produziert nur folgendes:

Code

NULL string(226673) "ޕ� ........

Ist mir auch aufgefallen. Allerdings macht das nichts, da $undefiniert += 1 == 1 ist und somit beim ersten read die Position initialisiert wird.
Das Problem bei mir war, dass substr sich manchmal um eine Stelle geirrt hat. Das hatte zur Folge, dass die readints bei load_table() ziemlichen Schrott geliefert haben (viel zu hohe Werte) und darauf hin versucht wurde, ein paar hunterttausend Strings einzulesen --> timeout.

Stelle gerade fest, dass mein Patch bei mir auch nicht richtig läuft, werde das jetzt mal ändern.

Update:
Wäh, dummer kleiner Fehler. Hier der aktuelle Patch:

class StringReader {
  var $_pos;
  var $_str;


  function StringReader($str='') {
    $this->_str = $str;
    $this->_pos = 0;
  }


  function my_substr($in, $pos, $len) {
    $out = "";
    for ($i = $pos; $i < $pos + $len; $i++) {
      $out .= $in[$i];
    };
    return $out;
  }


  function read($bytes) {
    $data = $this->my_substr($this->_str, $this->_pos, $bytes);
    $this->_pos += $bytes;
    if (strlen($this->_str)<$this->_pos)
      $this->_pos = strlen($this->_str);


    return $data;
  }

Hab ich eingebaut und kann zumindest schonmal bestätigen, dass es sprachlich keine Probleme zu geben scheint. Bleibt alles deutsch, jedoch dauert der Seitenaufbau meiner Meinung nach länger als vorher (aber das hatte codestyling ja glaub ich schon angekündigt...). Mal sehen ob sich da was in Sachen Fehlermeldungen ergibt.

Hab mich zwischenzeitlich auch mal in anderssprachigen WP Foren umgesehen. Das Problem besteht ja nicht nur mit der deutschen Sprachdatei. Auch andere sind betroffen, jedoch stehen Problemlösungen auch dort aus.

Ich hab heute morgen den gefunden Positionsfehler im Bugtrac eingekippt und es ist bereits jetzt ein Changeset verfügbar: #5599 (Sporadic timeout /wp-includes/gettext.php) - WordPress Trac - Trac

Es muß nicht nur das Positionsproblem sein, es kann je nach System (PHP Version und OS) eben auch noch zusätzlich der substr() Bug bzw. der fread() Bug eine Rolle spielen. Ich würde das mit der zusätzlichen fread() Anpassung laufen lassen, bei subst() ist die derzeitige Lösungs alles andere als optimal, wenn sie überhaupt nötig ist. Denn wenn die _pos irgendwo in data steht, dann liest man Phantasiewerte für die Stringanzahlen aus, was den gleichen Effekt haben dürfte.

Zitat von codestyling

[...] Denn wenn die _pos irgendwo in data steht, dann liest man Phantasiewerte für die Stringanzahlen aus, was den gleichen Effekt haben dürfte.

Das wird nicht passieren, siehe PHP: Variablen - Manual Der Default-Wert für Int ist 0, die Initialisierung spielt also keine Rolle. _pos wird immer richtig erhöht, nur liefert substr() leider nicht immer das, was man haben möchte. Ist wohl in der neuesten PHP-Version behoben.

Eine performante Lösung ist, die in WP nachimplementierte gettext-Funktion durch die entsprechende PHP-Funktion zu ersetzten - sofern vorhanden (s. PHP: Gettext - Manual ).

Zitat von Beatinu

Das wird nicht passieren, siehe PHP: Variablen - Manual Der Default-Wert für Int ist 0, die Initialisierung spielt also keine Rolle. _pos wird immer richtig erhöht, nur liefert substr() leider nicht immer das, was man haben möchte. Ist wohl in der neuesten PHP-Version behoben.

Eine performante Lösung ist, die in WP nachimplementierte gettext-Funktion durch die entsprechende PHP-Funktion zu ersetzten - sofern vorhanden (s. PHP: Gettext - Manual ).

Du vergisst dabei nur, das es mod_php mit zusätzlichen Bytecode Optimierern und Bytecode Caches gibt. Wenn in Stress-Situationen (was sowohl du als auch Infected beschreibt als "wenn was los ist auf meinen Seiten") der Bytecode vom File gerade noch rumliegt, dann kann der Inhalt der var auf sonst was stehen. Ich sag ja nicht, das substr() nicht fehlerhaft sein könnte, aber dieser Fehler sollte dann deutlich häufiger auftreten als nur bei Last.

Und noch was, auf 64 Bit Machinen kann die Zwangskonvertierung von NULL (siehe var_dump) zu negativen Werten führen mit der Konsequenz (PHP Subst):

Zitat

If start is negative, the returned string will start at the start 'th character from the end of string .

Ich hab das getestet. Bei allen Versuchen war _pos richtig. Das Verhalten von substr() war entweder richtig oder der ausgegebene String war eine Position zu weit vorne. Ich konnte das Verhalten fast zuverlässig ändern indem ich auf meiner phpBB-Installation eine Seite neu geladen habe. Das heißt natürlich nicht, dass _pos immer richtig sein muss. Ich habe _pos im richtigen Constructor auch mal initialisiert, aber das hat mein Problem nicht behoben.

Es könnte sein, dass substr() nur Äger macht, wenn der String lang ist und Apache schon eine Weile läuft. Da z.B. phpBB auch substr() verwendet und ich dort nie ein Problem hatte, gehe ich davon aus, dass die Stringlänge wichtig ist. Wenn ich den Apache neu starte, ist der Fehler für eine Weile (keine Ahnung, wie lange genau) weg.

Zitat von codestyling

Ich würde das mit der zusätzlichen fread() Anpassung laufen lassen, bei subst() ist die derzeitige Lösungs alles andere als optimal, wenn sie überhaupt nötig ist. ...

Soll heißen? War das überhaupt an mich gerichtet?

Ich wollte nur mal nen kurzen Zwischenstand abliefern. Ich teste ja gerade den letzten Code von Beatinu und nach ca 6 Stunden Dauerspeichern noch immer keine Fehlermeldung. Aber ich will mich nicht wieder zu früh freuen. Sah ja gestern zuerst auch ganz gut aus...

Fakt ist jedoch, dass dieser Code deutlich an den Ladezeiten zerrt. Ich werde gleich nochmal bis ca. 22 Uhr abwesend sein. Solange lass ich es mal weiterlaufen. Vielleicht tut sich ja noch was... Melde mich dann nochmal

Zitat von Beatinu

Ich hab das getestet. Bei allen Versuchen war _pos richtig. Das Verhalten von substr() war entweder richtig oder der ausgegebene String war eine Position zu weit vorne. Ich konnte das Verhalten fast zuverlässig ändern indem ich auf meiner phpBB-Installation eine Seite neu geladen habe. Das heißt natürlich nicht, dass _pos immer richtig sein muss. Ich habe _pos im richtigen Constructor auch mal initialisiert, aber das hat mein Problem nicht behoben.

Es könnte sein, dass substr() nur Äger macht, wenn der String lang ist und Apache schon eine Weile läuft. Da z.B. phpBB auch substr() verwendet und ich dort nie ein Problem hatte, gehe ich davon aus, dass die Stringlänge wichtig ist. Wenn ich den Apache neu starte, ist der Fehler für eine Weile (keine Ahnung, wie lange genau) weg.

Ich hab mal einen Test gestartet nur so zum Analysieren. Dabei hab ich mutwillig so initialisiert: $this->_pos = -100000000;
sofortiges Ergebnis (seitenlang):

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 91

Noch ein Test mit $this->_pos = 190000; liefert nur 4 Zeilen und dann english:

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 73
Warning: array_shift() [function.array-shift]: The argument should be an array in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 74
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 73
Warning: array_shift() [function.array-shift]: The argument should be an array in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 74

Da er in der 91'er Zeile nur anfängt wenn Pos negativ ist, sieht das nach einem int Problem auf 64bit Machinen bei nicht initialisierter _pos aus und die höherwertigen Bits sind alle 0xFF. Warum bei dir die Strings "nur" um 1 Zeichen verschoben sind, ist mir unklar. Dann dürftest du nur kaputte Strings haben haben aber keine 91'e Warning Zeile.

Wie ich schon sagte, die _pos-Werte fangen bei 0 an zu zählen, wenn du sie künstlich auf was anderes setzt, sind die Fehler klar und ähnlich. Das sollte aber bereits gleich am Anfang dazu führen, dass die Magic Cookies nicht gelesen werden können und gettext komplett aussteigt --> alles Englisch. Falls beim Cookie nicht ausgestiegen wird, dann stimmen die ausgelesenen Offsets für orginal und translation im .mo-File nicht mehr und das wiederum führt dazu, dass read() kein array liefert und die Fehlermeldung erscheint.

Bei mir stimmen die _pos-Werte bisher immer, damit lässt sich der Versatz jedenfalls nicht erklären. Zweimal substr() mit gleichen Parametern führt u.U. zu verschiedenen Ergebnissen.

Mein System ist übrigens Debian Etch i386. Wie es mit 64-Bit-OS aussieht, kann ich nicht sagen.

Selbst wenn man überprüft, ob substr() gerade mal den Versatz hat und ggf. nen Offset hinzuaddiert ist es nicht sicher, ob der Offset für alle folgenden substr() der Session gilt, das ist schonmal keine Lösung.

Noch was: Bei mir war es so, dass der Versatz erst beim Auslesen der .mo-Revision aufgetaucht ist. Wenn das zuverlässig sein sollte, könnte man bei $revision != 0 statt substr() my_substr() aufrufen. Sehr sehr unschön, aber eine Möglichkeit.

Zitat von Beatinu

Noch was: Bei mir war es so, dass der Versatz erst beim Auslesen der .mo-Revision aufgetaucht ist. Wenn das zuverlässig sein sollte, könnte man bei $revision != 0 statt substr() my_substr() aufrufen. Sehr sehr unschön, aber eine Möglichkeit.

Das schau ich mir mal an. Hier nur Ablauf, rekonstruiert, wie er bei Infected auftritt:
Original Fehlerbild von Infected:

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in /www/htdocs/xxx/test2/wp-includes/gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in /www/htdocs/xxx/test2/wp-includes/gettext.php on line 91
Fatal error: Maximum execution time of 30 seconds exceeded in /www/htdocs/xxx/test2/wp-includes/gettext.php on line 166

Mo-File einlesen:
1. streams.php fread() ganzer Fileinhalt

2. gettext.php Zeile: 122
$magic = $this->readint();
Byteorder ermitteln

3. gettext.php Zeile: 133
$revision = $this->readint();
Revision lesen

4. gettext.php Zeile: 135 - 137
$this->total = $this->readint();
$this->originals = $this->readint();
$this->translations = $this->readint();
Anzahl totaler Einträge lesen (int)
Anzahl der originale Lesen (int)
Anzahl der Übersetzungen lesen (int)

5. gettext.php Zeile: 257
$this->load_tables();
erster Aufruf lädt die Tabellen

6. gettext.php Zeile: 154 - 157
$this->STREAM->seekto($this->originals);
$this->table_originals = $this->readintarray($this->total * 2);
$this->STREAM->seekto($this->translations);
$this->table_translations = $this->readintarray($this->total * 2);
Original und Übersetzungtabellen arrays laden

7. gettext.php Zeile: 166
$translation = $this->STREAM->read($this->table_translations[$i * 2 + 1]);
Translation Eintrag lesen

Da er in gettext.php Zeile 166 nach 30 Sekunden hart beendet wurde, muß die Schleife, deren Zähler in 4.)
gelesen wurde, noch immer laufen, weil die Anzahl Einträge massiv groß ist, Zeile: 162
for ($i = 0; $i < $this->total; $i++) {

Nachtrag: Mofile Anfang:
DE 12 04 95 00 00 00 00 5E 08 00 00 1C 00 00 00
0C 43 00 00 29 0B 00 00 FC 85 00 00 00 00 00 00

$magic = 0x950412DE
$revision = 0x00000000
$this->total = 0x0000085E (Anzahl: 2142, ok)
$this->originals = 0x0000001C (Offset: 28 Bytes)
$this->translations = 0x0000430C (Offset: 17164 Bytes)

16164 - 28 Bytes = 17136 Byte / 2142 Einträge = 8 Bytes Breite = 4 Byte Offset + 4 Byte Länge

Bei mir war das genauso. Wenn der Fehler aufgetreten ist, stimmte nach dem magick cookie nichts mehr, weil alles versetzt war. Revision sollte 0 sein, war es aber schon nicht, da noch ein Byte aus dem Cookie dabei war. Totals, originals und translations waren entsprechend vermurkst, da gerade die höherwertigen Bytes nicht 0 sondern vom nachfolgenden Doubleword stammten und damit die Zahlen jenseits von 16777216 lagen.

Codestyling, ich glaube, du hast wenig Chancen den Fehler bei dir zu finden, wenn das Problem bei dir nicht auftritt.

Zitat von Beatinu

Codestyling, ich glaube, du hast wenig Chancen den Fehler bei dir zu finden, wenn das Problem bei dir nicht auftritt.

Sehr gut möglich. Aber evtl. könntest du ein var_dump für die ersten 10 Einträge hier reinbauen (gettext.php):

function readint() {
        if ($this->BYTEORDER == 0) {
            // low endian
            $low_end = unpack('V', $this->STREAM->read(4));
            [B]var_dump($low_end);[/B]
            return array_shift($low_end);
        } else {
            // big endian
            $big_end = unpack('N', $this->STREAM->read(4));
            [B]var_dump($big_end);[/B]
            return array_shift($big_end);
        }
    }

und das Ergebnis im Fehlerfall bereitstellen ?

Hallo ihr beiden!

Also nach ca. 11 Stunden Dauerspeichern habe ich mit folgendem Code von Beatinu zumindest für heute schonmal einen Erfolg zu verzeichnen

class StringReader {
  var $_pos;
  var $_str;


  function StringReader($str='') {
    $this->_str = $str;
    $this->_pos = 0;
  }


  function my_substr($in, $pos, $len) {
    $out = "";
    for ($i = $pos; $i < $pos + $len; $i++) {
      $out .= $in[$i];
    };
    return $out;
  }


  function read($bytes) {
    $data = $this->my_substr($this->_str, $this->_pos, $bytes);
    $this->_pos += $bytes;
    if (strlen($this->_str)<$this->_pos)
      $this->_pos = strlen($this->_str);


    return $data;
  }

Zwischenzeitlich hab ich hin und wieder mal ein bisschen zusätzliche "Last" erzeugt, indem ich an anderen Stellen des Blogs ein paar Eingriffe vorgenommen habe. Alles ohne irgendeine Fehlermeldung. Einziges Manko: Wie erwähnt ist hat sich die Geschwindigkeit in Sachen Seitenaufbau merklich verschlechtert. Wenn man den Code dahingehend noch optimieren könnte, würde ich mal einen Langzeittest starten um sicher zu gehen, dass ich heute nicht nur einen "Glückstag" hatte.

Ich muss zugeben, dass ich von euren letzten Postings nicht viel verstanden habe, dazu fehlt mir einfach das Fachwissen. Daher weiss ich auch nicht in wie weit eure Überlegungen fortgeschritten sind.

Trotzdem möchte ich mich jetzt schonmal für eure super Hilfe danken! Ist ja auch nicht gerade selbstverständlich...

Zitat von infected

Ich muss zugeben, dass ich von euren letzten Postings nicht viel verstanden habe, dazu fehlt mir einfach das Fachwissen. Daher weiss ich auch nicht in wie weit eure Überlegungen fortgeschritten sind.

Trotzdem möchte ich mich jetzt schonmal für eure super Hilfe danken! Ist ja auch nicht gerade selbstverständlich...

Nicht jeder muss alles können, nur wissen, wohin man sich wenden kann :)

Ich hab noch einen, gerade im Labortest: Da es ja offensichtlich die Index Adressierung zu den Strings zermüllert (manchmal jedenfalls), wäre es eine Option, einen korrekten Index (ohne Absturz und ohne substr) zu haben, auch wenn dann die Beschriftungen evtl. um 1 Zeichen verschoben sind (1. fehlt, dafür 1. von nächsten hinten dran) und der Speed dem von vorher entspricht?

Ist zwar auch eine Krücke aber besser als keine Seite ausliefern. Und im Frontend sollte es deutlich weniger auffallen und wenn dann beim nächsten Reload ggf. weg sein.

Da ich den Fehler ja nicht nachstellen kann, bin ich da limitiert, aber es gibt noch diese Umgehung. Wenn ich in Netz die Reports zum gleichen Thema lese, dann ist meist PHP 5.2.6 und Apache 2.x beteiligt. Auf Apache 1.x bzw PHP 4 scheint das nicht aufzutreten.

Zitat

auch wenn dann die Beschriftungen evtl. um 1 Zeichen verschoben sind (1. fehlt, dafür 1. von nächsten hinten dran)

Wie muss ich mir das vorstellen?

So? Artikel schreiben ---> rtikels chreiben ???

Wenn es so aussieht, wie ich mir das gerade vorstelle, dann bleib ich doch vorerst lieber bei den längeren Ladezeiten :-D