Fehlermeldungen nach Update auf 2.5

schwieriges Thema

Das ist in der Tat ein schwieriges Thema. Ich wühle mich schon den Abend über durch Blogs und Foren, und es mangelt da nicht an Lösungsvorschlägen. Nur funktioniert bisher bei mir keiner davon.

So wird beispielsweise behauptet, das sei ein Bug von PHP5, der aber ab Version 5.2.5 behoben sei. Nunja, ich habe PHP 5.2.6, und das Problem besteht weiterhin. Angeblich hilft es auch, das alte PHP 4 zu verwenden. Nur was, wenn man darauf keinen Einfluss hat?

Unter Brusdeylins » Blog Archiv » Probleme mit gettext wird eine vermeintliche Lösung beschrieben. Nur wie aus den Kommentaren hervor geht und ich selbst getestet habe, funktioniert diese Lösung in Wordpress 2.5 nicht mehr.

Ich bin übrigens wie Gnislew bei Host Europe. Haben die sich dazu mittlerweile mal geäußert? Würde mich sehr interessieren...

Nach Response Header ist der Server ein Apache/2.2 mit PHP/5.2.6.
Ist die WordPress Version schon auf 2.5.1 geupdated ?
Kannst du raus finden, ob das ein 64Bit System ist und wenn ja welches ?

Zeile 85 ist in WP2.5.1 nur Kommentar und kein Code enthalten.
Ich denke mal diese Funktion schlägt fehl (Zeile 85+3)

function readintarray($count) {
        if ($this->BYTEORDER == 0) {
            // low endian
            return unpack('V'.$count, $this->STREAM->read(4 * $count));
        } else {
            // big endian
            return unpack('N'.$count, $this->STREAM->read(4 * $count));
        }
    }

Wenn der Server z.B. eine Itanium Büchse ist, dann wäre big endian angesagt, aber der Fehler sagt ja, dass es bei

Zitat

Warning: unpack() [function.unpack]: [COLOR=Blue]Type V[/COLOR]

knallt.

Ich denke mal, dass es am Server liegt und WordPress mit der falschen BYTEORDER initialisiert wurde, weil der Server nicht richtig erkannt wurde.

Sowas müsste man auf genau diesem Server mal testen und könnte dann einen BugTrack Eintrag machen. Aber ohne so einen Server kann ich das nur vermuten und empirisch beurteilen.

Schön, dass ich nicht alleine bin... Erhalte seit einigen Tagen auch so ne feine Fehlermeldung:

Zitat

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

Angefangen hat´s vor knapp 2 Wochen, da erschien die Meldung mal sporadisch. Bis heute kam es vielleicht 3 Mal zu dieser Meldung. Heute Abend war es aber extrem schlimm. Mittlerweile kann ich meine Site so gut wie gar nicht mehr aufrufen. Habe auch schon einige Tipps ausprobiert, jedoch wie meine Vorredner zu keiner Lösung gekommen. :-|

Mögliche Lösung

Hallo!

Ich bin vorsichtig, vorzeitig einen Erfolg zu melden. Denn wie Ihr auch schreibt, tritt das Problem sporadisch auf - manchmal fast gar nicht, manchmal sehr oft.

Vielleicht ist es nur Zufall, aber es scheint mir als hätte der oben von marX beschriebene Tipp unter WordPress › Support » gettext error... can't solve bei mir geholfen. Mein Provider ermöglicht es, in der Server-Administration, eben diese "magic_quotes_runtime" Option von PHP auszuschalten. Nachdem ich das tat, ist mir das Problem in den letzten 24 Stunden nicht mehr untergekommen.

Ich war deshalb erstmal eher skeptisch, weil es in den vielen Foren und Blogs wirklich nicht an angeblichen Lösungen mangelt, die sich dann leider aber immer als großer Flopp herausstellten...

[COLOR="Red"]UPDATE 03.06.08: Zu früh gefreut. Das Problem besteht weiterhin. Die von marX und in diversen älteren Foren-Beiträgen beschriebene Lösung mit "magic_quotes_runtime" ist entweder unwirksam oder führt bestenfalls zu einer Minderung der Zahl an Fehlern, nicht aber zu einem Verschwinden des Problems.[/COLOR]

Also, ich habe beim meinen Testsystem folgendes mal eingeschaltet:

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = On

Daraufhin ging ein Anmelden gar nicht mehr (Weisse Seite Phänomen).
Dann hab ich den Language Ordner umbenannt, woraufhin beim Neuladen der Loginseite jetzt Fehlermeldungen erschienen aber eben immer noch kein Login!

Also hab ich die wp-config.php modifiziert und folgendes direkt nach den DB Definitionen eingetragen:

set_magic_quotes_runtime(0);

Somit gilt das sowohl fürs öffentliche Blog als auch fürs Backend.

Ergebnis: ich kann trotz per php.ini eingeschaltetem magic_quotes_runtime wieder das Blog und auch den Login und DashBoard benutzen. Da es nun erstmal englisch war, hab ich den Language Ordner wieder zurück benannt und schon war auch alles wieder deutsch.

Es sieht so aus als müsste man das nochmals ausschalten, bevor das erste Script per include/require geladen wird. Definitiv macht es aber die de_DE.mo Files beim Einlesen kaputt, denn diese PHP Option modifiziert Dateizugriffe und somit den Inhalt der *.mo Dateien beim Einlesen, da diese teilweise Binärdaten enthalten, deren 0x0000 in "\0" umgewandelt werden, was die

Zitat

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0

Fehler dann erzeugt.

Zitat von codestyling

Code

set_magic_quotes_runtime(0);

Somit gilt das sowohl fürs öffentliche Blog als auch fürs Backend.

Ergebnis: ich kann trotz per php.ini eingeschaltetem magic_quotes_runtime wieder das Blog und auch den Login und DashBoard benutzen. ...Definitiv macht es aber die de_DE.mo Files beim Einlesen kaputt, denn diese PHP Option modifiziert Dateizugriffe und somit den Inhalt der *.mo Dateien beim Einlesen, da diese teilweise Binärdaten enthalten, deren 0x0000 in "\0" umgewandelt werden, was die Fehler dann erzeugt.

Kannst Du mir das nochmal für Laien erklären? Wenn ich die oben erwähnte Zeile in die wp-config einfüge, zerschießt es mir dann die Sprachdatei, oder wie darf ich das verstehen?

Also, soll heißen:

1. Wenn magic_quotes_runtime = on (providerseitig) und
2. du ein de_DE.mo laden lässt

dann wird das geschrottet. Erst wenn ich magic_quotes_runtime ausmache, geht dann auch ein Sprachdatei und die Anmeldung wieder korrekt.
Besser formuliert ?

Ja, schon besser :mrgreen: Hab aber gerade mal nachgesehen: magic_quotes wurde von Seiten meines Providers (all-inkl) auf dem Server deaktiviert. Also kann´s ja eigentlich nicht daran liegen, oder?!

Nun ja, es gibt mehrere davon:

; Magic quotes
;


; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = On


; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off


; Use Sybase-style magic quotes (escape ' with '' instead of \').
magic_quotes_sybase = Off

Die mit explizit _runtime am Schluss ist ein Problem mit den *.mo Files.
Zwei Fragen noch:

1. Sicher, das auch die mit _runtime aus ist ?
2. Ist die Server Machine 64bit ?

zu 1) magic_quotes_gpc Off
magic_quotes_runtime Off
magic_quotes_sybase Off

zu 2) es handelt sich um ein 64Bit AMD-CPU, aber mit einem 32Bit-Suse Betriebssystem

Das klingt interessant. Es gab einen Patch in der gettext Implementierung, der sich mit der Erkennung von 64Bit Systemen auseinandersetzte. Mal so aus dem Bauch heraus: Wenn PHP meint, es wäre ein 64Bit Machine und deshalb den gettext magic 64bit machen will, obwohl das OS nur 32 Bit ist, dann könnte das in die Hose gehen.
Wenn du Lust auf Probieren hast, würde ich mit im Laufe des Tages mal die Stellen in WP ansehen (ist jetzt zu spät zum Denken) und testhalber dir den einen oder anderen Patch schicken. Wäre das ein Option, um das zu testen ?

Können wir gerne mal machen. Das Problem wird nur sein, dass der Fehler halt sporadisch auftritt und man so den Erfolg bzw. Misserfolg nur schwer beobachten kann. Die letzten Tage hatte ich eigentlich wieder Ruhe. Lediglich gestern Mittag kam es wieder häufiger zu diesen Fehlermeldungen, weswegen ich diesen Thread dann auch nochmal bemüht habe.

Ich wünsche dann erstmal angenehme Nachtruhe ;-)

Könnte sich um diesen PHP Bug handeln, der u.a. hier auch aufgetreten ist: #1484880 (Attachments get corrupted on Ubuntu server 64bit 6.06.2 LTS) - RoundCube Webmail - Trac
-> PHP Bugs: #35859: fread limited to 8K

Das *.mo File wird am Stück geladen, wie dieser Auszug aus dem WP Core zeigt:

// Preloads entire file in memory first, then creates a StringReader
// over it (it assumes knowledge of StringReader internals)
class CachedFileReader extends StringReader {
  function CachedFileReader($filename) {
    if (file_exists($filename)) {


      $length=filesize($filename);
      $fd = fopen($filename,'rb');


      if (!$fd) {
        $this->error = 3; // Cannot read file, probably permissions
        return false;
      }
      $this->_str = fread($fd, $length);
      fclose($fd);


    } else {
      $this->error = 2; // File doesn't exist
      return false;
    }
  }
}

Laut dem, was man in den Bugbeschreibungen im Netz findet (dazu gibt es eine Menge und auch neueren Datums!), gibt es einen Bug in PHP 5.1.1 (und höher ?) der statt der gesamten File Größe nur die ersten 8192 Bytes liest. Dies würde auch den Fehler erklären, warum dann 0 Bytes übrig sind, für die du eine Warnung bekommts.

Die WP Core Entwickler haben das auch für eine andere Klasse berücksichtigt und sogar kommentiert:

class FileReader {
.....
 function read($bytes) {
    if ($bytes) {
      fseek($this->_fd, $this->_pos);


      // PHP 5.1.1 does not read more than 8192 bytes in one fread()
      // the discussions at PHP Bugs suggest it's the intended behaviour
      while ($bytes > 0) {
        $chunk  = fread($this->_fd, $bytes);
        $data  .= $chunk;
        $bytes -= strlen($chunk);
      }
      $this->_pos = ftell($this->_fd);


      return $data;
    } else return '';
  }
....

Ich werde mal die Datei patchen und das blockweise Lesen auch in den CachedFileReader einbauen, testen und bereitstellen.
Mal sehen, ob das des Pudels Kern ist.

[COLOR=Red] getesteter Patch [/COLOR]
Datei: /wp-includes/streams.php
Zeile: 148 ff.
WP Version: 2.5.1

// Preloads entire file in memory first, then creates a StringReader
// over it (it assumes knowledge of StringReader internals)
class CachedFileReader extends StringReader {
  function CachedFileReader($filename) {
    if (file_exists($filename)) {


      $length=filesize($filename);
      $fd = fopen($filename,'rb');


      if (!$fd) {
        $this->error = 3; // Cannot read file, probably permissions
        return false;
      }
      
      // PHP 5.1.1 does not read more than 8192 bytes in one fread()
      // the discussions at PHP Bugs suggest it's the intended behaviour
      // ----- 2008-06-16 potential bug using *.mo Files -------------
      // FIXED: adapted from method read out of FileReader class
      while ($length > 0) {
        $chunk  = fread($fd, $length);
        $this->_str  .= $chunk;
        $length -= strlen($chunk);
      }
      
      //dont try in any case full file!   $this->_str = fread($fd, $length);
      fclose($fd);


    } else {
      $this->error = 2; // File doesn't exist
      return false;
    }
  }
}

Im Normalfall liest dieser Patch weiterhin das File am Stück, aber in dem Moment, wo das 8192 Bytes Limit Problem erscheint, wird das jetzt blockweise trotzdem komplett gelesen.

Ich hab den Code mal in meinem Testblog ersetzt. Mal sehen ob´s was bringt. Schonmal Danke für Deine Mühe!

Schade, wäre ja auch zu schön gewesen...

[Blockierte Grafik: http://img204.imageshack.us/img204/4933/unpackerrorsl8.png]

Zitat von infected

Schade, wäre ja auch zu schön gewesen...

[Blockierte Grafik: http://img204.imageshack.us/img204/4933/unpackerrorsl8.png]

Nach deinem Bild zu urteilen, ist das der schwarze "Kasten" mit dem Speichern/Publizieren Buttons, der nach x Sekunden dann die Autosave Mitteilung reinschreiben will, wenn er zwischengespeichert hat:

<p class="submit">
<input type="submit" class="button button-highlighted" tabindex="4" value="Speichern" id="save-post" name="save"/>
    <input type="submit" value="Publizieren" accesskey="p" tabindex="5" id="publish" class="button" name="publish"/>
<br class="clear"/>
<span id="autosave">[COLOR=Red][B]Entwurf gespeichert am 10:36:05.[/B][/COLOR]</span>
</p>

Dazu muß Autosave natürlich in die Übersetzung schauen, also das *.mo File aufmachen. Danke für den Hinweis, werd das mal weiter auseinandernehmen, warum er hier wieder mit der Übersetzung scheitert.
Da der Text impliziert, das da noch ein Datum rein müsste (am benutzen und nur Uhrzeit zeigen, ist blöd) kann es entweder ein Übersetzungfehler sein oder ein sprintf Bug an dieser Stelle im Code. Werd mal englisch testen...