Rozwiązanie problemu „Błąd krytyczny: osiągnięto maksymalny poziom zagnieżdżenia funkcji„ 100 ”, przerywanie!” w PHP

Zrobiłem funkcję, która wyszukuje wszystkie adresy URL w pliku html i powtarza ten sam proces dla każdej treści html połączonej z wykrytymi adresami URL. Funkcja jest rekurencyjna i może trwać bez końca. Jednak ograniczyłem rekursję, ustawiając zmienną globalną, która powoduje zatrzymanie rekursji po 100 rekurencjach.

Jednak php zwraca ten błąd:

Błąd krytyczny: osiągnięto maksymalny poziom zagnieżdżenia funkcji „100”, przerywanie! in D: \ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.php on line 1355

Znalazłem tutaj rozwiązanie: Zwiększenie limitu wywołań funkcji zagnieżdżania, ale to nie działa w moim przypadku.

Cytuję jedną z odpowiedzi z powyższego linku. Proszę, rozważ to.

„Czy masz zainstalowany Zend, IonCube lub xDebug? Jeśli tak, prawdopodobnie jest to źródło tego błędu.

Wpadłem na to kilka lat temu i skończyło się na tym, że Zend stawia to ograniczenie, a nie PHP. Oczywiście usunięcie go pozwoli> przekroczyć 100 iteracji, ale w końcu przekroczysz limity pamięci ”.

Czy istnieje sposób na zwiększenie maksymalnego poziomu zagnieżdżenia funkcji w PHP

Zwiększ wartość xdebug.max_nesting_levelw swoimphp.ini

Proste rozwiązanie rozwiązało mój problem. Właśnie skomentowałem tę linię:

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

w moim php.inipliku. To rozszerzenie ograniczało stos do, 100więc je wyłączyłem. Funkcja rekurencyjna działa teraz zgodnie z oczekiwaniami.

Zamiast korzystać z rekurencyjnych wywołań funkcji, pracuj z modelem kolejki, aby spłaszczyć strukturę.

$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;
}

Istnieją różne sposoby radzenia sobie z tym. Możesz śledzić więcej informacji, jeśli potrzebujesz wglądu w początek lub pokonywane ścieżki. Istnieją również kolejki rozproszone, które mogą działać na podobnym modelu.

Innym rozwiązaniem jest dodanie xdebug.max_nesting_level = 200pliku php.ini

Zamiast wyłączać xdebug, możesz ustawić wyższy limit, na przykład

xdebug.max_nesting_level = 500

Można to również naprawić bezpośrednio w php, na przykład w pliku konfiguracyjnym projektu.

ini_set('xdebug.max_nesting_level', 200);

Wejdź do pliku konfiguracyjnego php.ini i zmień następujący wiersz:

xdebug.max_nesting_level=100

na coś takiego:

xdebug.max_nesting_level=200

na Ubuntu przy użyciu PHP 5.59:
trzeba:

/etc/php5/cli/conf.d

i znajdź swój xdebug.ini w tym katalogu , w moim przypadku jest to 20-xdebug.ini

i dodaj tę linię `

xdebug.max_nesting_level = 200

albo to

xdebug.max_nesting_level = -1

ustaw ją na -1 i nie musisz się martwić o zmianę wartości poziomu zagnieżdżenia.

`

prawdopodobnie stało się to z powodu xdebug.

Spróbuj skomentować następujący wiersz w swoim „php.ini” i zrestartuj serwer, aby przeładować PHP.

  ";xdebug.max_nesting_level"

Spróbuj poszukać w /etc/php5/conf.d/, aby sprawdzić, czy jest plik o nazwie xdebug.ini

max_nesting_level to domyślnie 100

Jeśli nie jest ustawiony w tym pliku, dodaj:

xdebug.max_nesting_level=300

do końca listy, więc wygląda to tak

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

możesz następnie użyć testu @ Andrey'a przed i po wprowadzeniu tej zmiany, aby sprawdzić, czy zadziałało.

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

php.ini:

xdebug.max_nesting_level = -1

Nie jestem do końca pewien, czy wartość kiedykolwiek się przepełni i osiągnie -1, ale albo nigdy nie osiągnie -1, albo ustawia max_nesting_level dość wysoko.

Możesz przekonwertować swój rekurencyjny kod na kod iteracyjny, który symuluje rekurencję. Oznacza to, że musisz wypchnąć aktualny stan (adres URL, dokument, pozycja w dokumencie itp.) Do tablicy, gdy dotrzesz do łącza, i wyskoczyć z tablicy, gdy ten link się skończy.

Możesz spróbować ograniczyć zagnieżdżanie, wdrażając równoległe procesy robocze (jak w przypadku obliczeń klastrowych) zamiast zwiększać liczbę wywołań funkcji zagnieżdżania.

Na przykład: definiujesz ograniczoną liczbę slotów (np. 100) i monitorujesz liczbę „pracowników” przypisanych do każdego / niektórych z nich. Jeśli któryś z miejsc stanie się wolny, umieszczasz w nim oczekujących pracowników.

Sprawdź rekursję z wiersza poleceń:

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

jeśli wynik> 100 TO sprawdź limit pamięci;

Jeśli używasz Laravel, zrób

composer update

To powinno działać.

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

PS Zmień 9999 na dowolną liczbę.

Wystąpił błąd podczas instalowania wielu wtyczek, więc pokazał się błąd 100 zawierający lokalizację ostatniej zainstalowanej wtyczki C: \ wamp \ www \ mysite \ wp-content \ plugins \ "..." więc usunąłem tę wtyczkę folder na dysku C: wszystko wróciło do normy Myślę, że muszę ograniczyć ilość zainstalowanej wtyczki lub aktywowałem. powodzenia mam nadzieję, że to pomoże

W twoim przypadku zdecydowanie instancja robota ma większy limit Xdebug do śledzenia błędów i informacji debugowania.

Ale w innych przypadkach również błędy, takie jak w PHP lub plikach core, takich jak biblioteki CodeIgniter, utworzą taki przypadek i jeśli nawet zwiększysz ustawienie poziomu x-debug, nie zniknie.

Przyjrzyj się więc uważnie swojemu kodowi :).

Tutaj był problem w moim przypadku.

Miałem klasę usług, która jest biblioteką w CodeIgniter. Mając wewnątrz taką funkcję.

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

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

Mój kontroler w następujący sposób:

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

Wywołanie funkcji w ostatniej linii było błędne z powodu literówki, zamiast tego powinno wyglądać jak poniżej:

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

Następnie otrzymywałem komunikat o błędzie przekroczenia. Ale wyłączyłem XDebug, ale nie pomogło. W każdym razie sprawdź nazwę klasy lub kod pod kątem prawidłowego wywołania funkcji.

Miałem ten problem z WordPress na cloud9. Okazuje się, że była to wtyczka W3 Caching. Wyłączyłem wtyczkę i działało dobrze.

Inne rozwiązanie, jeśli uruchamiasz skrypt php w CLI (cmd)

Plik php.ini, który wymaga edycji, jest w tym przypadku inny. W mojej instalacji WAMP plik php.ini, który jest ładowany w wierszu poleceń, to:

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

zamiast \ wamp \ bin \ apache \ apache2.4.9 \ bin \ php.ini, który ładuje się, gdy php jest uruchamiany z przeglądarki

Możesz także zmodyfikować funkcję {debug} w modifier.debug_print_var.php, aby ograniczyć rekursję do obiektów.

Wokół linii 45, przed:

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

Po :

$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));

W ten sposób Xdebug nadal będzie zachowywał się normalnie: ogranicz głębokość rekursji w var_dump i tak dalej. Ponieważ jest to drobny problem, a nie Xdebug!

Miałem ten sam problem i tak mi się podoba:

Otwórz plik MySQL my.ini

W sekcji [mysqld] dodaj następujący wiersz: innodb_force_recovery = 1

Zapisz plik i spróbuj uruchomić MySQL

Usuń tę linię, którą właśnie dodałeś i Zapisz