Fehlermeldungen nach Update auf 2.5 - Seite 6

Beatinu · 18.06.2008, 11:27

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.

infected · 18.06.2008, 16:38

Zitat:

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

codestyling · 18.06.2008, 16:44

Zitat:

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):

Code:

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:

Code:

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.

Beatinu · 18.06.2008, 17:08

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.

codestyling · 18.06.2008, 17:39

Zitat:

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:

Code:

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

Beatinu · 18.06.2008, 18:10

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.

codestyling · 18.06.2008, 18:19

Zitat:

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):

Code:

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

und das Ergebnis im Fehlerfall bereitstellen ?

infected · 18.06.2008, 22:07

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

Code:

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...

codestyling · 18.06.2008, 23:10

Zitat:

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.

infected · 18.06.2008, 23:25

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