Lösung für "Schwerwiegender Fehler: Maximale Funktionsverschachtelung von '100' erreicht, Abbruch!" in PHP

Ich habe eine Funktion erstellt, die alle URLs in einer HTML-Datei findet und denselben Vorgang für jeden HTML-Inhalt wiederholt, der mit den erkannten URLs verknüpft ist. Die Funktion ist rekursiv und kann endlos fortgesetzt werden. Ich habe jedoch die Rekursion begrenzt, indem ich eine globale Variable festgelegt habe, die bewirkt, dass die Rekursion nach 100 Rekursionen gestoppt wird.

PHP gibt jedoch diesen Fehler zurück:

Schwerwiegender Fehler: Maximale Funktionsverschachtelungsstufe von '100' erreicht, Abbruch! in D: \ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.php in Zeile 1355

Ich habe hier eine Lösung gefunden: Das Limit für Aufrufe von Verschachtelungsfunktionen wird erhöht, aber dies funktioniert in meinem Fall nicht.

Ich zitiere eine der Antworten aus dem oben genannten Link. Bitte bedenken Sie es.

"Haben Sie Zend, IonCube oder xDebug installiert? Wenn ja, erhalten Sie diesen Fehler wahrscheinlich von dort.

Ich bin vor ein paar Jahren darauf gestoßen, und am Ende hat Zend diese Grenze gesetzt, nicht PHP. Wenn Sie es entfernen, können Sie natürlich die 100 Iterationen überschreiten, aber Sie werden schließlich die Speichergrenzen erreichen. "

Gibt es eine Möglichkeit, die maximale Funktionsverschachtelung in PHP zu erhöhen?

Erhöhen Sie den Wert von xdebug.max_nesting_levelin Ihremphp.ini

Eine einfache Lösung löste mein Problem. Ich habe gerade diese Zeile kommentiert:

zend_extension = "d:/wamp/bin/php/php5.3.8/zend_ext/php_xdebug-2.1.2-5.3-vc9.dll

in meiner php.iniAkte. Diese Erweiterung beschränkte den Stapel auf, 100sodass ich ihn deaktivierte. Die rekursive Funktion funktioniert jetzt wie erwartet.

Arbeiten Sie mit einem Warteschlangenmodell, um die Struktur zu reduzieren, anstatt rekursive Funktionsaufrufe durchzuführen.

$queue = array('http://example.com/first/url');
while (count($queue)) {
    $url = array_shift($queue);

    $queue = array_merge($queue, find_urls($url));
}

function find_urls($url)
{
    $urls = array();

    // Some logic filling the variable

    return $urls;
}

Es gibt verschiedene Möglichkeiten, damit umzugehen. Sie können weitere Informationen nachverfolgen, wenn Sie einen Einblick in den Ursprung oder die durchquerten Pfade benötigen. Es gibt auch verteilte Warteschlangen, die mit einem ähnlichen Modell arbeiten können.

Eine andere Lösung ist das Hinzufügen xdebug.max_nesting_level = 200in Ihrer php.ini

Anstatt den xdebug zu deaktivieren, können Sie das höhere Limit wie festlegen

xdebug.max_nesting_level = 500

Es ist auch möglich, dies direkt in PHP zu beheben, beispielsweise in der Konfigurationsdatei Ihres Projekts.

ini_set('xdebug.max_nesting_level', 200);

Gehen Sie in Ihre Konfigurationsdatei php.ini und ändern Sie die folgende Zeile:

xdebug.max_nesting_level=100

zu so etwas wie:

xdebug.max_nesting_level=200

unter Ubuntu mit PHP 5.59: muss
zu `:

/etc/php5/cli/conf.d

und finde deine xdebug.ini in diesem Verzeichnis , in meinem Fall ist 20-xdebug.ini

und füge diese Zeile hinzu `

xdebug.max_nesting_level = 200

oder dieses

xdebug.max_nesting_level = -1

Setzen Sie es auf -1 und Sie müssen sich keine Sorgen machen, den Wert der Verschachtelungsebene zu ändern.

`

wahrscheinlich wegen xdebug passiert.

Versuchen Sie, die folgende Zeile in Ihrer "php.ini" zu kommentieren, und starten Sie Ihren Server neu, um PHP neu zu laden.

  ";xdebug.max_nesting_level"

Suchen Sie in /etc/php5/conf.d/ nach einer Datei mit dem Namen xdebug.ini

max_nesting_level ist standardmäßig 100

Wenn es nicht in dieser Datei festgelegt ist, fügen Sie hinzu:

xdebug.max_nesting_level=300

bis zum Ende der Liste, so sieht es aus

xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=/home/drupalpro/websites/logs/profiler
xdebug.max_nesting_level=300

Sie können dann den Test von @ Andrey vor und nach dieser Änderung verwenden, um festzustellen, ob er funktioniert hat.

php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'

php.ini:

xdebug.max_nesting_level = -1

Ich bin nicht ganz sicher, ob der Wert jemals überlaufen und -1 erreichen wird, aber er wird entweder nie -1 erreichen oder den max_nesting_level ziemlich hoch setzen.

Sie können Ihren rekursiven Code in einen iterativen Code konvertieren, der die Rekursion simuliert. Dies bedeutet, dass Sie den aktuellen Status (URL, Dokument, Position im Dokument usw.) in ein Array verschieben müssen, wenn Sie einen Link erreichen, und ihn aus dem Array entfernen müssen, wenn dieser Link fertig ist.

Sie können versuchen, die Verschachtelung zu verringern, indem Sie parallele Worker implementieren (wie beim Cluster-Computing), anstatt die Anzahl der Aufrufe von Verschachtelungsfunktionen zu erhöhen.

Beispiel: Sie definieren eine begrenzte Anzahl von Slots (z. B. 100) und überwachen die Anzahl der "Arbeitern", die jedem / einigen von ihnen zugewiesen sind. Wenn irgendwelche Slots frei werden, setzen Sie die wartenden Arbeiter "in sie".

Überprüfen Sie die Rekursion über die Befehlszeile:

php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'

wenn Ergebnis> 100 DANN Speicherlimit prüfen;

Wenn Sie Laravel verwenden, tun Sie dies

composer update

Das sollte Arbeit sein.

<?php
ini_set('xdebug.max_nesting_level', 9999);
... your code ...

PS Ändern Sie 9999 in eine beliebige Zahl.

Ich hatte einen Fehler, als ich viele Plugins installiert habe. Der Fehler 100 zeigte also den Speicherort des letzten Plugins an, das ich installiert habe. C: \ wamp \ www \ mysite \ wp-content \ plugins \ "...", also habe ich dieses Plugin gelöscht Ordner auf dem Laufwerk C: dann war alles wieder normal. Ich denke, ich muss die Anzahl der Plug-Ins, die ich installiere oder aktiviert habe, begrenzen. Viel Glück, ich hoffe, es hilft

In Ihrem Fall hat die Crawler-Instanz definitiv mehr Xdebug-Limit, um Fehler- und Debug-Informationen zu verfolgen.

In anderen Fällen führen jedoch auch Fehler wie bei PHP oder Kerndateien wie CodeIgniter-Bibliotheken zu einem solchen Fall, und wenn Sie die Einstellung für die X-Debug-Ebene sogar erhöhen, verschwindet sie nicht.

Schauen Sie sich also Ihren Code genau an :).

Hier war das Problem in meinem Fall.

Ich hatte eine Serviceklasse, die Bibliothek in CodeIgniter ist. Eine Funktion wie diese haben.

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

  public function process(){
   //lots of Ci referencing here...
   }

Mein Controller wie folgt:

$this->load->library('PaymentService');
$this->process_(); // see I got this wrong instead  it shoud be like 

Der Funktionsaufruf in der letzten Zeile war wegen des Tippfehlers falsch, stattdessen sollte er wie folgt aussehen:

$this->Payment_service->process(); //the library class name

Dann bekam ich immer wieder die Fehlermeldung "Überschreiten". Aber ich habe XDebug deaktiviert, aber nicht geholfen. Überprüfen Sie auf jeden Fall Ihren Klassennamen oder Ihren Code auf ordnungsgemäße Funktionsaufrufe.

Ich hatte dieses Problem mit WordPress auf Cloud9. Es stellte sich heraus, dass es sich um das W3-Caching-Plugin handelte. Ich habe das Plugin deaktiviert und es hat gut funktioniert.

Eine andere Lösung, wenn Sie PHP-Skript in CLI (cmd) ausführen

Die zu bearbeitende Datei php.ini ist in diesem Fall anders. In meiner WAMP-Installation lautet die in die Befehlszeile geladene Datei php.ini:

\wamp\bin\php\php5.5.12\php.ini

anstelle von \ wamp \ bin \ apache \ apache2.4.9 \ bin \ php.ini, das geladen wird, wenn PHP vom Browser ausgeführt wird

Sie können die Funktion {debug} auch in modifier.debug_print_var.php ändern, um die Rekursion in Objekte zu begrenzen.

Um die Linie 45 herum, bevor:

$results .= '<br>' . str_repeat('&nbsp;', $depth * 2)
  . '<b> -&gt;' . strtr($curr_key, $_replace) . '</b> = '
  . smarty_modifier_debug_print_var($curr_val, ++$depth, $length);

Nach dem :

$max_depth = 10;
$results .= '<br>' . str_repeat('&nbsp;', $depth * 2)
  . '<b> -&gt;' . strtr($curr_key, $_replace) . '</b> = '
  . ($depth > $max_depth ? 'Max recursion depth:'.(++$depth) : smarty_modifier_debug_print_var($curr_val, ++$depth, $length));

Auf diese Weise verhält sich Xdebug weiterhin normal: Begrenzen Sie die Rekursionstiefe in var_dump und so weiter. Da dies ein kluges Problem ist, kein Xdebug!

Ich hatte das gleiche Problem und ich liebe es wie folgt:

Öffnen Sie die MySQL my.ini-Datei

Fügen Sie im Abschnitt [mysqld] die folgende Zeile hinzu: innodb_force_recovery = 1

Speichern Sie die Datei und versuchen Sie, MySQL zu starten

Entfernen Sie die gerade hinzugefügte Zeile und speichern Sie sie