Рішення для "Фатальної помилки: Максимальний рівень вкладення функції" 100 "досягнуто, перервавшись!" в PHP

Я створив функцію, яка знаходить всі URL-адреси в HTML-файлі і повторює той самий процес для кожного вмісту html, пов'язаного з виявленими URL-адресами. Ця функція є рекурсивною і може тривати нескінченно. Однак я поставив обмеження на рекурсію, встановивши глобальну змінну, яка змушує припинити рекурсію після 100 рекурсій.

Однак php повертає цю помилку:

Фатальна помилка: досягнуто максимального рівня гніздування функції «100», перервавшись! в D: \ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.php по лінії 1355

Тут я знайшов рішення: збільшення ліміту викликів функції вкладення, але в моєму випадку це не працює.

Я цитую одну з відповідей за згаданим вище посиланням. Будь ласка, врахуйте це.

"У вас встановлені Zend, IonCube чи xDebug? Якщо так, то, ймовірно, звідки ви отримуєте цю помилку.

Я натрапив на це кілька років тому, і в кінцевому підсумку Zend поставив ту межу, а не PHP. Звичайно, його видалення дозволить вам пройти повний 100 ітерацій, але ви зрештою досягнете межі пам'яті ".

Чи є спосіб підвищити максимальний рівень вкладення функції в PHP

Збільште значення xdebug.max_nesting_levelвашихphp.ini

Просте рішення вирішило мою проблему. Я щойно прокоментував цей рядок:

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

в моєму php.iniфайлі. Це розширення обмежувало стек, щоб 100я його відключив. Рекурсивна функція зараз працює так, як передбачалося.

Замість того, щоб приймати рекурсивні виклики функцій, працюйте з моделлю черги, щоб вирівняти структуру.

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

Існують різні способи впоратися з цим. Ви можете відслідковувати додаткову інформацію, якщо вам потрібно ознайомитись з походженням або пройденими шляхами. Також є розподілені черги, які можуть працювати з подібною моделлю.

Ще одне рішення - додати xdebug.max_nesting_level = 200у свій php.ini

Замість того, щоб вимкнути xdebug, ви можете встановити вищу межу, як

xdebug.max_nesting_level = 500

Це також можна виправити безпосередньо в php, наприклад, у конфігураційному файлі вашого проекту.

ini_set('xdebug.max_nesting_level', 200);

Зайдіть у свій конфігураційний файл php.ini та змініть такий рядок:

xdebug.max_nesting_level=100

до чогось типу:

xdebug.max_nesting_level=200

в Ubuntu за допомогою PHP 5.59:
дісталося до `:

/etc/php5/cli/conf.d

і знайдіть свій xdebug.ini в цьому dir, в моєму випадку це 20-xdebug.ini

і додайте цей рядок `

xdebug.max_nesting_level = 200

або це

xdebug.max_nesting_level = -1

встановіть його на -1, і вам не доведеться турбуватися про зміну значення рівня гніздування.

`

ймовірно, сталося через xdebug.

Спробуйте прокоментувати наступний рядок у "php.ini" та перезапустіть сервер, щоб перезавантажити PHP.

  ";xdebug.max_nesting_level"

Спробуйте заглянути в /etc/php5/conf.d/, щоб побачити, чи є файл з назвою xdebug.ini

max_nesting_level за замовчуванням 100

Якщо він не встановлений у цьому файлі, додайте:

xdebug.max_nesting_level=300

до кінця списку, щоб він виглядав так

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

ви можете використовувати тест @ Andrey до і після внесення цієї зміни, щоб побачити, чи працює.

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

php.ini:

xdebug.max_nesting_level = -1

Я не зовсім впевнений, що коли-небудь значення переповниться і досягне -1, але воно ніколи не досягне -1, або він встановить максимальний_випуск_рівень досить високим.

Ви можете перетворити свій рекурсивний код в ітераційний код, який імітує рекурсію. Це означає, що вам доведеться натиснути поточний статус (URL, документ, позиція в документі тощо) у масив, коли ви досягнете посилання, і вискочити його з масиву, коли це посилання закінчиться.

Ви можете спробувати вимкнути гніздування, застосовуючи паралельних робітників (наприклад, в кластерних обчисленнях), а не збільшуючи кількість викликів функцій вкладки.

Наприклад: ви визначаєте обмежену кількість слотів (наприклад, 100) і стежите за кількістю «працівників», призначених для кожного / деяких з них. Якщо будь-які слоти стають безкоштовними, ви кладете робітників, що чекають, "в них".

Перевірте рекурсію з командного рядка:

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

якщо результат> 100 THEN перевірити обмеження пам’яті;

Якщо ви використовуєте Laravel, зробіть це

composer update

Це має бути робота.

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

PS Змініть 9999 на будь-яке число, яке вам потрібно.

У мене виникла помилка, коли я встановлював багато плагінів. Отже, помилка 100 показала, включаючи розташування останнього плагіна, який я встановив C: \ wamp \ www \ mysite \ wp-content \ plugins \ "...", тому я видалив цей плагін папка на C: диск тоді все повернулося до норми. Я думаю, що мені доведеться обмежити кількість плагінів, які я встановлю або активував.

У вашому випадку, безумовно, екземпляр сканера має більше межі Xdebug для відстеження інформації про помилки та налагодження.

Але в інших випадках також помилки, такі як у PHP або основних файлах, таких як бібліотеки CodeIgniter, створять такий випадок, і якщо ви навіть збільшите налаштування рівня x-debug, це не зникне.

Тож уважно вивчіть свій код :).

Ось питання було в моєму випадку.

У мене був клас обслуговування, який є бібліотекою в CodeIgniter. Маючи функцію всередині такої.

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

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

Мій контролер наступним чином:

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

Виклик функції на останньому рядку був помилковим через помилку друку, натомість він повинен був бути як нижче:

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

Тоді я продовжував отримувати повідомлення про помилку перевищення. Але я відключив XDebug, але не допоміг. Будь-який спосіб, будь ласка, перевірте ваше ім'я класу або код, щоб правильно функціонувати.

У мене виникла ця проблема з WordPress на cloud9. Виявляється, це був плагін W3 Caching. Я відключив плагін і він працював чудово.

Ще одне рішення, якщо ви використовуєте php-скрипт у CLI (cmd)

Файл php.ini, який потребує редагування, відрізняється в цьому випадку. У моїй установці WAMP файл php.ini, завантажений у командному рядку, є:

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

замість \ wamp \ bin \ apache \ apache2.4.9 \ bin \ php.ini, який завантажується при запуску php із браузера

Ви також можете змінити функцію {debug} в modifier.debug_print_var.php, щоб обмежити її рекурсію в об'єкти.

Приблизно лінія 45 перед:

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

Після:

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

Таким чином, Xdebug все ще буде вести себе нормально: обмежте глибину рекурсії у var_dump тощо. Оскільки це розумна проблема, а не Xdebug!

У мене була така ж проблема, і я перекладаюсь так:

Відкрийте файл My.QL my.ini

У розділі [mysqld] додайте такий рядок: innodb_force_recovery = 1

Збережіть файл і спробуйте запустити MySQL

Видаліть щойно доданий рядок та збережіть