Apache crash – php5ts.dll

Heute hatte ich ein sehr „spannendes“ Problem auf meinem lokalen Testserver. Szenario: Eine normale TYPO3 Website eines Kunden, die ich mir auch am lokalen Server eingerichtet habe damit ich größere Änderungn zuerst lokal entwicklen und testen kann. In dieser Website kommen u.a. Extbase Erweiterungen zum Einsatz, daher werden auch Fluid Templates verwendet.

In einem Template wird ein Partial eingebunden, dem ein paar Parameter übergeben werden – soweit nichts ungewöhnliches, funktionierte in der Form sowohl am Live-Server als auch lokal wunderbar:

Hier musste ich einen Parameter hinzufügen sodass sich folgender Abschnitt ergab:

Es kam also der Parameter paperGrades hinzu. Mit diesem Parameter im Code stürzte der Apache beim Seitenaufruf komplett ab und der Browser zeigte eine nette Fehlermeldung. „Fehler: Verbindung unterbrochen. Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.“ – kennt man ja.

Zuerst dachte ich es liegt am neuen paperGrades Parameter, doch es stellte sich heraus dass es völlig egal ist welchen Parameter ich hinzufüge – Sobald es 8 waren verabschiedete sich der Apache. Entfernte ich z.B. currentPid funktionierte wieder alles (bis auf den fehlenden Parameter innerhalb des Partials natürlich).

Gut jetzt ging es an die Fehlersuche.

Apache Error log:

Hier sieht man nur dass der Prozess abgestürzt ist und neu gestartet wurde. Auch mit LogLevel auf debug waren hier keine relevanten Informationen sichtbar.

Die Windows Ereignisanzeige ist schon etwas aufschlussreicher, aber auch noch nicht der Bringer:

Also ist nicht der Apache selbst schuld, sondern das PHP Modul. Hilft einem aber „normalerweise“ auch nicht weiter.

Da ich aber weiß dass in Fluid für das Template-parsing reguläre Ausdrücke verwendet werden, hatte ich die Vermutung dass ihm der 8. Parameter einfach zu viel war. In der Regel stellt das kein Problem dar, ich hatte schon längere Regex-Patterns im Einsatz und auch schon größere Fluid Objekte wie in diesem Template – die funktionierten alle problemlos, allerdings nicht am lokalen Windows sondern auf einem richtigen Linux Server.

Mit dieser Vermutung ging es also ans Googeln und ich fand den PHP Bug #47689.
Demnach handelt es sich hier um einen Stack Overflow, den man aber mittels Erhöhung der ThreadStackSize in der httpd.conf eliminieren kann:

Apache neu starten, fertig!

Dauerte eine Weile bis ich auf die Lösung kam aber man hat ja sonst nichts zu tun 😉
Es gab auch noch andere Hinweise, u.a. auf eine fehlerhafte dll von MySQL die man durch eine andere ersetzen sollte, aber das passte bei mir nicht ins Fehlerbild.

Setup:

  • Windows 7
  • Apache 2.2.22
  • PHP 5.3.13
  • MySQL 5.5.24

PS: Dieses Problem scheinen aktuell auch einige Leute mit XAMP/WAMP in Verbindung mit dem Extension Manager in TYPO3 V6 zu haben.

23 Gedanken zu „Apache crash – php5ts.dll“

  1. Hallo,
    ich hab das hier gerade per google gefunden und wollte Danke sagen.

    Danke! 🙂

    Du hast mir gerade wahrscheinlich Stunden von Fehler suchen erspart. Ich hab XAMPP 1.8.1 auf Windows Vista installiert und wollte TYPO3 6.0rc1 ausprobieren und wenn ich im Backend in den Extension Manager rein wollte ist mit der Apache mit dem gleichen Fehler abgestuerzt. Dein Tipp hat das aber geloest. Danke vielmals!

    Beste Gruesse
    Stefan

      1. Das selbe bei mir:

        Typo3 v6.0.0 lokal auf XAMPP installiert und der Extensionmanager zwang immer den Apache in die Knie.

        Vielen Dank für das teilen deiner Erkenntnisse. Auch mir hat dieser Beitrag wohl Stunden an Fehlersuche erspart.

        Gruss
        Markus

  2. Pingback: Anonymous
  3. Der Hinweis darauf steht bei TYPO3 übrigens auch im Install Tool unter Basic Configuration:

    ThreadStackSize

    Fluid uses complex regular expressions which require a lot of stack space during the first processing. On Windows the default stack size for Apache is a lot smaller than on unix. You can increase the size to 8MB (default on unix) by adding to the httpd.conf:

    ThreadStackSize 8388608

    Restart Apache after this change.

  4. Bei meiner lokalen Testinstallation mit dem aktuellen Typo3 Winstaller und der aktuellen Typo3 6.0 Version unter Windows Vista 32 Bit hat die Änderung der httpd.conf keine Auswirkungen gehabt.

    Mein Extensionmanager kann ich aufrufen, aber er scheint nach jedem Klick abzustürzen und die Seite bleibt im BE leer.

    Was kann ich tun?

    1. Hallo Martin, dazu wäre es wichtig zu wissen was die Windows Ereignisanzeige und das Apache Errorlog sagt. Bitte auch prüfen ob du das error_reporting aktiviert hast – dazu im Install Tool displayErrors auf 1 setzen oder auf 2 + devIPmask entsprechend setzen, evtl. bekommst du ja dann einen Fehler angezeigt.

      Ein anderes häufiges Problem ist auch das nesting level. Setze mal in der php.ini xdebug.max_nesting_level = 200, schaden kann das nicht.

  5. Hallo Alexander,

    ein wirklich hilfreicher Artikel, vielen Dank!

    Vielleicht noch ein Hinweis, weil es mich anfangs ein wenig in die Irre geführt hat:

    Ich hatte dieses Problem in einer Apache 2.0-Umgebung. Obiger Code-Schnipsel ließ sich zwar problem- und fehlerlos in die httpd.conf einbetten, hatte jedoch keinen Effekt. Der Grund: ThreadStackSize gibt es erst seit Apache 2.1:http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadStackSize

    Dass der Apache-Service nicht schon beim Start abschmierte, lag an der IfModule-Anweisung, die zumindest bei mir dafür sorgte, dass die Zeile nicht ausgeführt wurde.

    Habe nun eine 2.2er Umgebung eingerichtet und konnte das Problem mit einer Erhöhung der ThreadStackSize beheben.

    Danke! 🙂

  6. DANKE! Hatte eben genau das gleiche Problem mit TYPO3 4.7 und den Extensions Flux, VHS, Fluidpages und Fluidcontent. 2 Stunden lang herumprobiert, nun dies hier gefunden.

    Letztes mal konnte ich es nur durch Neuinstallation von WAMP lösen, wusste aber nicht woran es genau lag.

    Dickes Dankeschön!

  7. Nach stundenlangem Debuggen bin ich endlich auf deine Seite gestoßen. Danke für den Hinweis, ich wäre da nicht alleine drauf gekommen…

    Bei mir handelte es sich um einen WordPress Blog, der bei do_shortcode exakt an der Stelle

    return preg_replace_callback( ‚/‘ . $pattern . ‚/s‘,
    array( &$this, ‚do_shortcode_tag‘ ), $content );
    }

    abgestürzt ist. Keine Fehlermeldung, kein 404 – im Webentwickler nur „aborted“ für die GET-Anfrage. Bei mir stand auch nichts im PHP- oder Apache Logfile

  8. Viele Dank dafür! 🙂

    Das hat das Problem bei Typo3 mit dem PHP-Crash durch das Laden der Liste im ExtensionManager auf meinem localhost behoben.

    Grüße

  9. Danke.

    Auch mir hast du Stunden von Arbeit erspart. Nachdem ich Typo3 6.1 nicht zum laufen gebracht hatte wollte ich es mit der 6.2 beta versuchen.

    Als der Apache beim Aufrufen des Extension immer abschmierte war ich nahe daran wieder zu meiner 4.5 LTS Installation zurückzukeheren.

    Gruss Crawfish

  10. Kann mich den Vorrednern nur anschließen. Google nach „typo3 6.2 extension manager crashes apache“ führte direkt hierher und brachte den gewünschten Erfolg mit dem Typo3 Extension Manager. Danke 🙂

  11. Vielen Dank! Ich habe lange vergeblich  nach einer Lösung gesucht.

    Bei mir trat das Problem unter WAMP und unter XAMP mit Joomla bei Start des JCE Editors auf.

    Gruss Kolibri

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.