PHP stüzt ab, memory size exhausted, Log-File wird zugemüllt

[trent]

Hallo zusammen,

ich habe Schwierigkeiten, folgenden Fehler einzugrenzen und nach langer Suche im Netz nichts wirklich hilfreiches gefunden.
Auch ein Update von 3.5.0 auf 3.5.3 hat nichts gebracht.

Wenn Crawler auf meine Seite zugreifen, benutzen sie häufig die URL [domain]/[eineSeite]?page_e56=[eine Zahl]
Der URL-Parameter führt dazu, dass ein 404 generiert wird -- ich weiß auch gar nicht, warum die Crawler das tun.

Jedenfalls führt (auch der manuelle Aufruf) einer solchen Seite zu langen Ladezeiten (ca. 2 Minuten) ohne Ergebnis oder manchmal einem Internal Server Error
des Webservers, was wohl den memory size exhausted fehler im error-log generiert. In der Zeit ist die Seite nicht mehr erreichbar.

Ja, genau: so einfach ist es im Moment die Seite zu crashen. Jetzt hab ich erst mal die robots verboten. Noch viel schlimmer ist, dass im System-Log nicht nur
ein Eintrag bzgl. des gescheiterten Versuchs, die Seite aufzurufen steht, sondern gleich etwa 600. In kürzester Zeit werden die Logs so mit 10000en Zeilen geflutet.
Mein erster Gedanke war, dass es ein stack-overflow-error durch wiederholte Funktionsaufrufe sein könnte, bei dem immer die Log-Meldungen generiert wird.

Das passiert tatsächlich nur mit dem Attribut page_e56 und noch einigen anderen page_...-Attributen.

Habt ihr Tipps, um den Fehler einzugrenzen? Könnte das evtl. auch ein Sicherheitsproblem für contao sein, da so ja auch ein DOS-Angriff denkbar wäre. Der
Fehler in der error.log lautet

Allowed memory size of 134217728 bytes exhausted (tried to allocate 36 bytes) in
    [ausgeblendet]/system/modules/core/pages/PageRegular.php on line 441

Edit: Vielleicht noch ein paar weitere Sachen. In einer älteren Error-Log-Datei habe ich einen Backtrace gefunden, der meine Vermutung mit den Funktionsaufrufen
bestätigt.

#23 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/pages/PageError404.php(102): Contao\PageRegular->generate(Object(Contao\PageModel))
#24 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/calendar/modules/ModuleEventlist.php(207): Contao\PageError404->generate('19')
#25 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/modules/Module.php(282): Contao\ModuleEventlist->compile()
#26 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/calendar/modules/ModuleEventlist.php(70): Contao\Module->generate()
#27 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/library/Contao/Controller.php(313): Contao\ModuleEventlist->generate()
#28 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/pages/PageRegular.php(133): Contao\Controller::getFrontendModule(Object(Contao\ModuleModel), 'right')
#29 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/pages/PageError404.php(102): Contao\PageRegular->generate(Object(Contao\PageModel))
#30 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/calendar/modules/ModuleEventlist.php(207): Contao\PageError404->generate('19')
#31 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/modules/Module.php(282): Contao\ModuleEventlist->compile()
#32 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/calendar/modules/ModuleEventlist.php(70): Contao\Module->generate()
#33 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/library/Contao/Controller.php(313): Contao\ModuleEventlist->generate()
#34 /mnt/web7/c0/03/5231803/htdocs/mpg/system/modules/core/pages/PageRegular.php(133): Contao\Controller::getFrontendModule(Object(Contao\ModuleModel), 'right')
usw.

Das geht bis Zeile 10363

[Znrl]

Generell reicht her der Speicher nicht,

Wie sind denn deine URLs normal aufgebaut?
Das klingt nämlich nicht nach normalen Contao Seiten insbesondere, da ohne index.php.

Da könnten noch Seiten indexiert sein von einer früheren Version der Website.
trotzdem sollte das nicht zu so einem Verhalten führen.

Prüf deine Installation mal mit dem Contao Check.

Sicherer als die robots.txt wäre erstmal solche anfragen per .htaccess zu filtern.

RewriteCond %{QUERY_STRING} ^page_e56=(.*)$ [NC]
RewriteRule ^.*$ http://www.domain.de? [R=301,L]

Das leitet alles, was "page_e56=" enthält auf die Startseite
Vtl. anpassen, falls du das auf eine Error Seite leiten willst oder auch andere Varianten des Querystrings vorkommen.
Ob 301 hier passt müsstest du vtl. wissen.

Dann wäre aber noch die Frage warum der Fehler kommt.

Funktionieren denn andere "falsche" URLs bzw. Querystrings?
Also wird dort korrekterweise die Error Page angezeigt o.ä.? Also mal sowas wie "?test=123" anhängen und schauen.

Edit:
Grad dein Edit gesehen, interessant wäre die erste Zeile der Fehlermeldung, in der steht um was es sich handelt.
Aber es scheint so, als würde es beim erstellen der Fehlerseiten 404 zu dem Fehler kommen.
Dann dürftest du vtl. mit allen falsch eingegeben URLs probleme haben, die Contao verarbeitet?
Oder wird hier pro Event ein Fehler generiert undeshalb der Speicherverbrauch?

Definitiv mal den Contao Check drüberlaufen lassen.
https://github.com/contao/check

[tab]

Ich würde auch mal die .htaccess durchforsten im Hinblick darauf, was mit nicht gefundenen Seiten passiert und ob eventuell vernünftige URLs durch irgendwelche Regeln in solche URLs umgeschrieben werden.

[trent]

Danke für die Antworten! Generell sind nicht alle URLs, die 404s generieren, betroffen, d.h. die Fehlerseite wird i.d.R. richtig angezeigt (nur bei genanntem page_e-Parameter nicht). Das Filtern in der .htaccess ist eine gute Idee, allerdings vermute ich, dass es noch andere page_e...-Parameter gibt, die zu diesem Fehler führen. Es führen auch wirklich nur dieser Parameter zu genanntem Zustand, ein beliebig konstruierter Parametername nicht.
Das hängt wohl damit zusammen, dass contao page_e-Parameter zur Pagination von Event-Listen verwendet. (worauf ich gestoßen bin, als ich in die im Backtrace angegebenen Dateien geschaut habe, und zwar in system/modules/calendar/modules/ModuleEventlist.php. Und aus irgendeinem Grund mag er gerade page_e56 nicht.

Die .htaccess hatte ich auch schon als Verursacher im Verdacht, habe daher mal testweise die .htaccess.default, die mit den contao-Installationen mitgeliefert wird (ohne meine persönlichen Anpassungen) eingestellt, aber da tritt der Fehler auch auf.

Wenn ich den Fehler richtig verstehe, bietet php 134217728B = 128MB Arbeitsspeicher an, was IMHO eigentlich für contao reichen sollte (aber das ist keine qualifizierte Bemerkung, sondern nur meine Meinung ). So ohne weiteres kann ich daran auch nichts ändern, da ich keinen dedizierten Server habe. Aber offensichtlich gibt es hier ja diese nicht terminierende Schleife von Funktionsaufrufen, das kann man PHP nicht in die Schuhe schieben.

Achso, ich verwende mod_rewrite, um den Eindruck von statischen Seiten zu machen (mit Endung .html) und schönere Links zu haben. Trotzdem können aber Parameter über "?...&..." übergeben werden (z.B. zur Pagination oder zur Wahl des Monats im Kalender).

[tab]

Ich kann das zumindest gefühlt nachvollziehen. Wenn ich bei einer existierenden Seite deine Parameter mit übergebe, nicht weil da irgendwas dahinterstecken würde, sondern just for fun, dann bekomme ich zwar keinen Fehler. Aber es dauert wesentlich länger, bis ich dann letztlich doch auf der existierenden Seite lande. Da geht es allerdings eher um ein paar Sekunden, sicher nicht um Minuten. Das Ganze ebenfalls unter Contao 3.5.3.

[trent]

Ich werde jetzt die Webseite bei mir lokal replizieren und dann mal versuchen, ob ich den Fehler erzeugen kann. Wenn ich einen Debugger installiert bekomme, step ich durch den Code, dann werden wir mal sehen.

[trent]

Für die, die das hier noch interesssiert ein kleiner Fortschrittsbericht meiner Debug-Versuche:

Ich habe den Fehler lokal nachvollziehen können; es handelt sich tatsächlich um eine Art rekursive Schleife ohne Abbruch (wie in meinem ersten Post geschildert). Die mysteriöse Zahl 56 bezieht sich wohl auf die DB-id eines Moduls, bei mir ist das ein Eventlist-Modul. Ich habe das Modul mal kopiert und das Original (56) gelöscht. Die Kopie hat id 167 bekommen; jetzt tritt der Fehler bei page_e167=irgendwas auf.

Ich versuche jetzt parallel, die demo.contao.org durch ähnliche Einstellungen zum Absturz zu bringen, bis jetzt ohne Erfolg, trotzdem vermute ich den Fehler dort. Ich habe bei mir

Anzahl der Events: 0
Elemente pro Seite: 12

Stelle ich das auf die Werte des Eventlist-Moduls aus der Contao-Demo-Installation (Anzahl der Events: 6, Elemente pro Seite 0), dann tritt der Fehler nicht mehr auf. Leider führen meine Einstellungen in der Contao-Demo-Installation nicht zum Fehler, also muss noch mehr dahinter stecken.

Vielleicht habt ihr ja noch Ideen?

[Znrl]

Hast du das clean afgesetzt?
Ein Contao Check wäre sonst noch was.

Wie viele Events sind denn das?
Wenn du sagst 10k+ Zeilen ist das ein einziger Fehler?

Wenn es viele Events sind, wird wohl für jedes Event ein Fehler produziert. Dann vtl. mal einige löschen, vtl. kommt man dem schneller auf die schliche wenn was ausgegeben wird und der Speicher reicht.
Du müsstest mal die Kalendereinstellungen etc. testen vtl. mal die Events in der DB anschauen, ob da irgendwas fehlt oä.

[trent]

Nein, ich hab einfach die Webseite samt Datenbank kopiert, um es leichter testen zu können. Ich habe aber auch eine Contao-Installation neu aufgesetzt, da tritt der Fehler nicht auf. Contao check liefert keine Probleme. Der Fehler tritt auf, auch wenn nur ein Event im Kalender ist. Er wird nicht von zu vielen Events generiert, hab ich alles schon ausprobiert, das hatte ich auch zunächst gedacht. Ich hab nochmal nachgeschaut: pro Aufruf werden im Falle eines Fehlers ca. 1500-2500 Log-Einträge generiert, unabhängig von der Anzahl der Events in der DB.
Ich versuche immer noch den "Kreis", der da mit den Methoden-Aufrufen entsteht, zu verstehen. Da ich mich aber mit dem "Ablauf" im Quellcode eines Contao-Seitenaufrufs nicht auskenne und auch nicht mit den dazugehörigen Klassen, dauert das Debugging, außerdem bin ich jetzt erst mal 5 Tage weg.

[Spooky]

Interessant, wieder mal was zum debuggen, werde mir das auch mal ansehen wenn ich Zeit hab'

[trent]

So, ich hab das Problem gefunden. Ich bin mir aber nicht sicher, ob man man das als Bug in Contao bezeichnen kann, denn den Loop habe ich eigentlich selbst gebaut.

Also: Der GET-Parameter "page_eXXX" gibt die Pagination für das Eventlist-Modul Nr. XXX an, sein Wert die entsprechende Seitenzahl. Wenn ich also page_e123=4 angebe, soll in der Eventlist die Seite 4 angezeigt werden. Gibr es keine Seite 4, weil nicht genügend Events dargestellt werden, so dass sich 4 Seiten ergäben, so generiert Contao in ModuleEventlist.php:203-208 eine 404-Seite. Diese hat bei mir ein Seitenlayout, dass wiederum das entsprechende Eventlist-Modul in einer Seitenspalte verwendet. Da der GET-Parameter auch der 404-Seite mit übergeben wird, wird erneut in ModuleEventlist eine 404-Seite generiert.

Was wären jetzt also Lösungen? Z.B. könnte ich ein Seitenlayout verwenden, bei dem das Eventlist-Modul nicht verwendet wird, dann wird der entsprechende Parameter ignoriert. Schöner wäre es natürlich, wenn der Parameter der 404-Seite nicht weitergereicht würde, denn warum soll ich unbedingt auf meine Event-List auf der 404-Seite verzichten? Braucht man Parameter in der URL auf einer 404-Seite?
Ich finde es allerdings unschön und problematisch, dass aus dem Funktionen-Stack zum Seitenaufbau aus einem Modul heraus eine Funktion aufgerufen wird, die eine neue Seite generiert, die die gerade aufzubauende ersetzen wird. Besser wäre doch, eine Art 404-Flag zu setzen, die Modul-Abarbeitung abzubrechen, auf dem Stack "zurückzuspulen" etwa bis PageRegular::generate oder noch davor, und dann eben stattdessen die 404-Seite zu generieren. [Ich hoffe ich hab mich klar genug ausgedrückt ]

Man kann das Verhalten übrigens leicht in der Demo von Contao nachbauen; dazu setzt man einfach im Modul "Calendar - Event list footer" die Einstellung "Number of Events" auf 0 und "Items per Page" z.B. auf 12 (die Eventlist steht im Footer der 404-Seite). Wenn man jetzt page_e35=20 setzt ("Calendar - Event list footer" hat id=35), also auf eine Seitenzahl, die in der Pagination nicht vorkommt, tritt oben beschriebenes Verhalten ein -- hier werden aber "nur" ca. 30 Fehler in die Syslog geschrieben.

Nachtrag:
Ich hab gerade mal geschaut: diese Technik, eine 404-Seite beim Paginieren zu generieren, findet sich noch in weiteren Modulen, z.B. ModulesNewsArchive, ModulesNewsList, ... In allen Fällen kann man, wenn die 404-Seite diese Module wieder verwendet, den beschriebenen Absturz herbeiführen.

[Znrl]

Hm wenn ich das so mache, werde ich auf die Startseite geleitet (ohne Parameter) und es gibt eine (1) Fehlermeldung im Syslog.
Das ist in der Online Demo: http://demo.contao.org/en/, mit deiner Anleitung.

[trent]

...ups; das liegt daran, dass die 404-Seite im Demo ein 302-Redirect auf die Homepage ist; das muss man deaktivieren (also nicht "Forward to another page" aktivieren), dann kommt der Fehler. Hatte ich vergessen zu erwähnen.

[Spooky]

…, und dann eben stattdessen die 404-Seite zu generieren. [Ich hoffe ich hab mich klar genug ausgedrückt ]

Naja, das löst ja das Problem nicht, sobald die 404 Seite generiert wird, hast du wieder dasselbe Problem.

Link zum Issue: https://github.com/contao/core/issues/8060

[trent]

Ja, das stimmt, hab ich mittlerweile auch kapiert .

Im Moment tendiere ich auch eher dazu, dass es kein Bug ist, weil man die Schleife selbst baut. Vielleicht sollte man eher in der Doku darauf hinweisen, beim Erstellen der 404-Seiten aufzupassen. Außer in der Demo habe ich beim Ausprobieren einiger Contao-Fallstudien-Webseiten auch keine gefunden, die einen Kalender oder ein anderes paginierbares Modul auf ihrer 404-Seite nutzt und auch in der Demo muss man die Paginierung und die 404-Seite ja erst aktivieren. Vielleicht ist es nicht so wichtig.

[Spooky]

Ich würde es schon als Bug einstufen, jedoch fällt mir da spontan keine echte Lösung ein. Es ist halt unschön, dass man auf so etwas Rücksicht nehmen muss bei der 404 Seite.

// eine Lösung würde mir schon einfallen:

if( $objPage->type != 'error_404' )
{
    /** @var \PageError404 $objHandler */
    $objHandler = new $GLOBALS['TL_PTY']['error_404']();
    $objHandler->generate($objPage->id);
} 

Elegant ist das aber auch nicht.

[Znrl]

Das Problem bzgl 404 oder nicht dürfte wohl sein, dass man nicht generell weiß wie die (paginierte) Eventliste (oder andere Elemente) eingebunden ist.

Es kann tatsächlich die Seite www.domain.de/eventliste sein, bei der die Eventliste im Mittelpunkt steht oder eben auch nur eine x-beliebige Site, bei der die Eventliste an der Seite oder im Footer steht.
In erstem Fall ist es wohl ein 404. Im zweiten Fall eher nicht, da hier der Parameter eher modizifierend als dominierend bzgl. der Seite wirkt.

Vtl. vergleichbar mit einem Schriftgrößenwechsler.

Da Events sehr variabel in der Anzahl sind ist es sehr wahrscheinlich, dass in diversen Leszeichen und im Index von Suchmaschinen etc. paginierungs Parameter (als "Beiwerk") auftauschen, die nicht (immer) existieren und sonst jedes mal etwas anderes anzeigen.

Wenn man es nicht als 404 ansieht könnte man den Parameter ignorieren (und damit auf die erste Seite der Pagination leiten) oder
ein "paginations-fehler-template" anzeigen.
Im Sinne "Die Seite 42 der Eventliste exisiert nicht. << < 1 2 3 ... > >> (>> = letzte exisierende Seite anzeigen).

[Spooky]

Früher, also vor Contao 3.5.0, gab es das Problem nicht, da einfach folgendes gemacht wurde:

// Send a 404 header
header('HTTP/1.1 404 Not Found');
return; 

https://github.com/contao/core/blob/...tlist.php#L203