"치명적 오류 : 최대 기능 중첩 수준 '100'에 도달했습니다. 중단했습니다!"

"치명적 오류 : 최대 기능 중첩 수준 '100'에 도달했습니다. 중단했습니다!" PHP에서

---

html 파일 내에서 모든 URL을 찾고 검색 된 URL에 연결된 각 html 컨텐츠에 대해 동일한 프로세스를 반복하는 기능을 만들었습니다. 이 함수는 재귀 적이며 끝없이 진행될 수 있습니다. 그러나 100 회 재귀 후 재귀가 중지되도록 전역 변수를 설정하여 재귀를 제한했습니다.

그러나 PHP는 다음 오류를 반환합니다.

치명적인 오류 : 최대 기능 중첩 수준 '100'에 도달하여 중단되었습니다! D : \ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.php의 1355 행

여기에서 해결책을 찾았습니다 : 중첩 함수 호출 제한을 늘리지 만 제 경우에는 작동하지 않습니다.

위에서 언급 한 링크의 답변 중 하나를 인용하고 있습니다. 그것을 고려하십시오.

"Zend, IonCube 또는 xDebug가 설치되어 있습니까? 그렇다면이 오류가 발생했을 수 있습니다.

몇 년 전에이 문제가 발생하여 PHP가 아닌 Zend가 그 한계를 뛰어 넘었습니다. 물론 이것을 제거하면 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;
}

There are different ways to handle it. You can keep track of more information if you need some insight about the origin or paths traversed. There are also distributed queues that can work off a similar model.

---

Another solution is to add xdebug.max_nesting_level = 200 in your php.ini

---

Rather than disabling the xdebug, you can set the higher limit like

xdebug.max_nesting_level=500

---

It's also possible to fix this directly in php, for example in the config file of your project.

ini_set('xdebug.max_nesting_level', 200);

---

Go into your php.ini configuration file and change the following line:

xdebug.max_nesting_level=100

to something like:

xdebug.max_nesting_level=200

---

on Ubuntu using PHP 5.59 :
got to `:

/etc/php5/cli/conf.d

and find your xdebug.ini in that dir, in my case is 20-xdebug.ini

and add this line `

xdebug.max_nesting_level = 200

or this

xdebug.max_nesting_level = -1

set it to -1 and you dont have to worry change the value of the nesting level.

`

---

probably happened because of xdebug.

Try commenting the following line in your "php.ini" and restart your server to reload PHP.

  ";xdebug.max_nesting_level"

---

Try looking in /etc/php5/conf.d/ to see if there is a file called xdebug.ini

max_nesting_level is 100 by default

If it is not set in that file add:

xdebug.max_nesting_level=300

to the end of the list so it looks like this

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

you can then use @Andrey's test before and after making this change to see if worked.

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

---

php.ini:

xdebug.max_nesting_level = -1

I'm not entirely sure if the value will ever overflow and reach -1, but it'll either never reach -1, or it'll set the max_nesting_level pretty high.

---

You could try to wiggle down the nesting by implementing parallel workers (like in cluster computing) instead of increasing the number of nesting function calls.

For example: you define a limited number of slots (eg. 100) and monitor the number of "workers" assigned to each/some of them. If any slots become free, you put the waiting workers "in them".

---

You could convert your recursive code into an iterative code, which simulates the recursion. This means that you have to push the current status (url, document, position in document etc.) into an array, when you reach a link, and pop it out of the array, when this link has finished.

---

Check recursion from command line:

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

if result > 100 THEN check memory limit;

---

If you're using Laravel, do

composer update

This should be work.

---

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

P.S. Change 9999 to any number you want.

---

I had a error when i was installing many plugins So the error 100 showed including the location of the last plugin that i installed C:\wamp\www\mysite\wp-content\plugins\"..." so i deleted this plugin folder on the C: drive then everything was back to normal.I think i have to limit the amount of plug-in i install or have activated .good luck i hope it helps

---

In your case it's definitely the crawler instance is having more Xdebug limit to trace error and debug info.

But, in other cases also errors like on PHP or core files like CodeIgniter libraries will create such a case and if you even increase the x-debug level setting it would not vanish.

So, look into your code carefully :) .

Here was the issue in my case.

I had a service class which is library in CodeIgniter. Having a function inside like this.

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

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

My controller as follow:

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

Function call on last line was wrong because of the typo, instead it should have been like below:

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

Then I was keeping getting the exceed error message. But I disabled XDebug but non helped. Any way please check you class name or your code for proper function calling.

---

I had this issue with WordPress on cloud9. It turns out it was the W3 Caching plugin. I disabled the plugin and it worked fine.

---

Another solution if you are running php script in CLI(cmd)

The php.ini file that needs edit is different in this case. In my WAMP installation the php.ini file that is loaded in command line is:

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

instead of \wamp\bin\apache\apache2.4.9\bin\php.ini which loads when php is run from browser

---

You can also modify the {debug} function in modifier.debug_print_var.php, in order to limit its recursion into objects.

Around line 45, before :

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

After :

$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가 아닌 현명한 문제입니다!

참고 URL : https://stackoverflow.com/questions/8656089/solution-for-fatal-error-maximum-function-nesting-level-of-100-reached-abor