Beiträge von codestyling

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.

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

Wusste doch, das ich eine vernüftige Erklärung schon gelesen hatte von Putzlowitsch: http://forum.wordpress-deutschland.org/konfiguration/…html#post111917

Zitat von infected

Ich trau mich fast gar nicht es zu sagen, aber ich denke/hoffe das Problem hat sich gelöst. Bislang keinerlei Fehler.

Hoffentlich war´s dann auch die entgültige Lösung. Dann hätte Alphawolf mit seiner Aussage doch noch recht

Ich bin ja auch für einfache Lösungen und wenn es geht, dann ist es ja für Produktivsysteme ok. Aber dennoch bin ich nicht zufrieden mit dieser Lösung, denn:

Wenn ein ungeänderter Programmcode 100 mal mit exakt den gleichen Eingangsdaten (was dein permanentes Zwischenspeichern ja ist) funktioniert und bei der 101ten Ausführung plötzlich nicht mehr, dann ist da was faul.
Gleicher Code und identischer Input kann keine 2 Resultate haben.

Wenn ich die Threads hier so querlese, scheint des Öfteren das Plugin cforms eine Rolle zu spielen, wenn etwas nicht mehr so geht, wie es soll.
Ist nur so eine Idee, falls das jemand von benutzt, dies testhalber zu deaktivieren.

Zitat von infected

Was testen?

Wenn du Alphawolf's Vorschlag durch hast, und es immer noch passiert, wäre Beatinu's Patch der nächste Versuch, so meinte ich das, sorry.
Wäre schon übel, sollte es unter Stress-Situationen in der substr() Funktion zu solchen spontanen Problemen kommt!

Es wäre gut, wenn infected das ebenfalls mal testen könnte, ich würde mir heute abend einen performanten Workarround überlegen. Deshalb wäre ein bestätigter Test, das es daran liegt, sehr wertvoll.

Zitat von Reitmeier

Hi,
das ganze schon mal mit nem anderen Virenscanner getestet?
Nur um mal etwas gewissheit zu bekommen.
cu

Gleiche Aktionen durchgeführt, wie vorher nur unter Kontrolle von McAfee VirusScan Enterprise 8.5i und es wird nichts beanstandet.
Allerdings wurde zwischenzeitlich der TinyMCE Editor gegen den FCKEditor ausgetauscht.

Hab es gerade im FireFox ausprobiert. Es verhält sich genau wie die schreibst, neue Klassen sind erstmal nicht zu sehen.
Ändert auch nichts, wenn man Shift+Reload benutzt. Erst wenn ich den Browsercache leeren lasse und reload der Seite mache, sind auch die neuen Klassen drin. Das ist ein bekanntes Problem bei der Auslieferung von javascript basierten Dateien bzw bei der Auslieferung von CSS Dateien.

Zitat von Beatinu

So, hab auch mal ne Weile debugt, da mein Blog auch mit dem Fehler "Type V: not enough input, need 4, have 0 [...]" ausgestiegen ist. Das Problem trat erst nach einer Weile auf und hing davon ab, was auf meinen anderen Seiten los war (gleiche Installation). Für mich sieht es nach einem Fehler von substr() aus.

Und hier ein passender PHP Bug, der schon gemeldet wurde: PHP Bugs: #40754: substr() checks overflow

Zitat

<?php

$v = 2147483647; # INT_MAX on 32bit Linux

# Tries to allocate too much memory
var_dump(substr("abcde", 1, $v));

var_dump(substr_replace("abcde", "x", $v, $v));

Allerdings immer byteweise zu vergrößern, wäre ein Performance Problem, denn ein de_DE.mo enthält > 2000 Textpaare, von den int's mal ganz abgesehen !

Lösch mal die vorkomprimierten Editorfiles auf der Domain, meist ist dieses Caching Schuld am nicht anzeigen.

wp-content\uploads\js_cache\tinymce(md5).gz

Danach Shift+Reload im FireFox und es sollte jetzt drin sein.
Wenn es dennoch nicht angezeigt wird, blendet ein anderes Plugin oder dein Theme dort sein Stylesheet ein.

Das kommt ganz darauf an, wer die Stylesheet Benutzung in den Editor einblendet. Zum einen kann TinyMCE Advanced ein Stylesheet File in den Editor einblenden (dort in Dokumentation nachzulesen), weiterhin gibt es Themes, die ihr Stylesheet dort einblenden und es gibt wie in deinem Fall vermutlich Shutter Reloaded Plugin, das ebenfalls ein Stylesheet dort einblendet.
Wenn sich mehrere drum schlagen, wer sein Stylesheet dort einblenden darf, kann das schon mal nach hinten losgehen.
Zu diesem Thema hab ich ein Mini-Plugin geschrieben, das ebenfalls ein Stylesheet einblenden kann, wenn der Benutzer keinen "aufgeblasenen" Editor für seine Kunden haben will (also ohne Themeunterstützung und ohne TinyMCE Advanced). Du kannst dir das auch gern codetechnisch ansehen, in deinen Plugins und Themes danach suchen und dich dann entscheiden, wessen Styleerweiterung du benutzen willst.

Zitat von Alphawolf

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

Es wird die komplette Gettext Bibliothek geladen. Daher nachwievor mein Verdacht, dass es einfach an PHP Limits liegt. Habe gerade geschaut, ich habe auch 30 Sek. als max_execution_time. Interessant wäre daher nochmal die phpinfo, welchen Wert er bei Memory Limit hat.

Einspruch, Euer Ehren!
Der translate() Aufruf erfolgt in der Mapper Klasse class gettext_reader, die wiederum ihre Implementation auf einen Member der Klasse class CachedFileReader aufsetzt. Dieser wird bei Initialisieren die de_DE.mo komplett in den Speicher laden und alle seek, tell und sonstigen Aufrufe basieren auf dem $this->_str Inhalt, der ja schon gelesen wurde (binärer, kompletter Fileinhalt).

Wenn ich also einen int auspacken lassen will, ist die Data schon im Speicher, es sei denn ich hab nur die Table of Contents Struktur aus der de_DE.mo lesen können und der seek weis zwar wohin er soll, aber da ist nix mehr.

Und wie gesagt, der Aufruf und Aufbau der Admin Seite zum Editieren der Posts verbraucht mehr Speicher als der Aufruf der Ajax Funktion, die maximal einen Text String returned.

Zitat von SuMu

mit AVG ist auch nix auffällig

Was hab ich gemacht:

1. eingeloggt mit info/info
2. Schreiben -> neuer Artikel
3. rechte Maustaste im FireFox -> Quelltext anzeigen

Ergebnis: Avira heult auf mit Warnung vor o.g. Trojaner. Konnte bloss keinen Schadcode finden.

Zitat von F.LM

WordPress › Collapsing Categories « WordPress Plugins

Hast du irgend eine Begrenzung angegeben oder hat das Plugin tatsächlich alle Posts, die du je gemacht hast auf deiner Hauptseite verlinkt und nur per Javascript "versteckt"? Ohne Begrenzung hast du Google eben mal alle >2000 Links auf der Main Page präsentiert, was bei einer Domain, die schon Google gut bekannt ist, dazu führen kann, dass der Bot alle >2000 Seiten am Stück besucht !

Das führt zu > 2000 heftigen Datenbankabfragen, ich denke du wirst damit eher die DB Server lahmgelegt haben als den WebServer.

Was Caching angeht, das ist nicht mein Gebiet, sorry. Du könntest höchstens das Plugin per FTP löschen (dessen Pluginorder) dann läuft es nicht mehr und dann den Provider bitten, wieder zuzuschalten.

Hast du einen Link zum Plugin Download ?

Hast du etwa versucht, Google und Yahoo diese Anzahl von Seiten innerhalb kürzester Zeit anzudrehen ?

[SIZE=-1]Ergebnisse 1 - 10 von ungefähr 2.270 von http://www.f-lm.de.

Das muß in die Hose gehen, wenn das die Bot's drüberrauschen bei der Größe der Texte.
[/SIZE]