1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

Fehlermeldungen nach Update auf 2.5

Dieses Thema im Forum "Installation" wurde erstellt von Gnislew, 3. Mai 2008.

  1. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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:.
     
  2. mfitzen

    mfitzen Well-Known Member

    Registriert seit:
    9. Juli 2006
    Beiträge:
    9.820
    Zustimmungen:
    2
    Getestet und für nicht gut befunden. Diese Änderung zerschießt mir z.B. die Übersetzung des Simple Forums.
     
  3. Beatinu

    Beatinu Member

    Registriert seit:
    17. Juni 2008
    Beiträge:
    10
    Zustimmungen:
    0
    Schade. Was passiert genau?
     
  4. mfitzen

    mfitzen Well-Known Member

    Registriert seit:
    9. Juli 2006
    Beiträge:
    9.820
    Zustimmungen:
    2
    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
     
  5. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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:
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Die _pos vom StringReader wird nicht initialisiert durch den CachedFileReader (parent Constructor nicht aufgerufen)! Die blaue Ausgabe produziert nur folgendes:
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    @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 ?
     
    #45 codestyling, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  6. Beatinu

    Beatinu Member

    Registriert seit:
    17. Juni 2008
    Beiträge:
    10
    Zustimmungen:
    0
    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:

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
     
    #46 Beatinu, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  7. mfitzen

    mfitzen Well-Known Member

    Registriert seit:
    9. Juli 2006
    Beiträge:
    9.820
    Zustimmungen:
    2
    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.
     
  8. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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.
     
    #48 codestyling, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  9. Beatinu

    Beatinu Member

    Registriert seit:
    17. Juni 2008
    Beiträge:
    10
    Zustimmungen:
    0
    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 ).
     
  10. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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):
     
    #50 codestyling, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  11. Beatinu

    Beatinu Member

    Registriert seit:
    17. Juni 2008
    Beiträge:
    10
    Zustimmungen:
    0
    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.
     
  12. mfitzen

    mfitzen Well-Known Member

    Registriert seit:
    9. Juli 2006
    Beiträge:
    9.820
    Zustimmungen:
    2
    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
     
  13. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    Ich hab mal einen Test gestartet nur so zum Analysieren. Dabei hab ich mutwillig so initialisiert: $this->_pos = -100000000;
    sofortiges Ergebnis (seitenlang):
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Noch ein Test mit $this->_pos = 190000; liefert nur 4 Zeilen und dann english:
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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.
     
    #53 codestyling, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  14. Beatinu

    Beatinu Member

    Registriert seit:
    17. Juni 2008
    Beiträge:
    10
    Zustimmungen:
    0
    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.
     
    #54 Beatinu, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  15. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    Das schau ich mir mal an. Hier nur Ablauf, rekonstruiert, wie er bei Infected auftritt:
    Original Fehlerbild von Infected:
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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
     
    #55 codestyling, 18. Juni 2008
    Zuletzt bearbeitet: 18. Juni 2008
  16. Beatinu

    Beatinu Member

    Registriert seit:
    17. Juni 2008
    Beiträge:
    10
    Zustimmungen:
    0
    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.
     
  17. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    Sehr gut möglich. Aber evtl. könntest du ein var_dump für die ersten 10 Einträge hier reinbauen (gettext.php):
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    und das Ergebnis im Fehlerfall bereitstellen ?
     
  18. mfitzen

    mfitzen Well-Known Member

    Registriert seit:
    9. Juli 2006
    Beiträge:
    9.820
    Zustimmungen:
    2
    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:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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...
     
  19. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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.
     
  20. mfitzen

    mfitzen Well-Known Member

    Registriert seit:
    9. Juli 2006
    Beiträge:
    9.820
    Zustimmungen:
    2
    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
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden