Fehlermeldungen nach Update auf 2.5

[codestyling]

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 .

[infected]

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

[Beatinu]

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?

[infected]

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

[codestyling]

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.
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 {
  var $_pos;
  var $_str;

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

  function read($bytes) {
  var_dump($this->_pos);
    var_dump($this->_str);
    exit;

Die _pos vom StringReader wird nicht initialisiert durch den CachedFileReader (parent Constructor nicht aufgerufen)! Die blaue 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 ?

[Beatinu]

Zitat von codestyling

Die _pos vom StringReader wird nicht initialisiert durch den CachedFileReader (parent Constructor nicht aufgerufen)! Die blaue Ausgabe produziert nur folgendes:

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;
  }

[infected]

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.

[codestyling]

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.

[Beatinu]

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

[codestyling]

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

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