Solution for "Fatal error: Maximum function nesting level of '100' reached, aborting!" in PHP

Question

I have made a function that finds all the URLs within an html file and repeats the same process for each html content linked to the discovered URLs. The function is recursive and can go on endlessly. However, I have put a limit on the recursion by setting a global variable which causes the recursion to stop after 100 recursions.

However, php returns this error:

Fatal error: Maximum function nesting level of '100' reached, aborting! in D:\\wamp\\www\\crawler1\\simplehtmldom_1_5\\simple_html_dom.php on line 1355

I found a solution here: Increasing nesting function calls limit but this is not working in my case.

I am quoting one of the answers from the link mentioned above. Please do consider it.

"Do you have Zend, IonCube, or xDebug installed? If so, that is probably where you are getting this error from.

I ran into this a few years ago, and it ended up being Zend putting that limit there, not PHP. Of course removing it will let >you go past the 100 iterations, but you will eventually hit the memory limits."

Is there a way to increase the maximum function nesting level in PHP

Answer 1

增加php.ini中xdebug.max_nesting_level的值

Answer 2

A simple solution solved my problem. I just commented this line:

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

in my php.ini file. This extension was limiting the stack to 100 so I disabled it. The recursive function is now working as anticipated.

Answer 3

另一种解决方案是在 php.ini 中添加xdebug.max_nesting_level = 200

Answer 4

Rather than going for a recursive function calls, work with a queue model to flatten the structure.

$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.

Answer 5

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

xdebug.max_nesting_level=500

Answer 6

也可以直接在 php 中修复此问题，例如在项目的配置文件中。

ini_set('xdebug.max_nesting_level', 200);

Answer 7

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

Answer 8

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.

`

Answer 9

probably happened because of xdebug.

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

Answer 10

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();'

Answer 11

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.

Answer 12

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.

Answer 13

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;

Answer 14

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

PS Change 9999 to any number you want.

Answer 15

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".

Answer 16

If you're using Laravel, do

composer update

This should be work.

Answer 17

Stumbled upon this bug as well during development.

However, in my case it was caused by an underlying loop of functions calling eachother - as a result of continuous iterations during development.

For future reference by search engines - the exact error my logs provided me with was:

Exception: Maximum function nesting level of '256' reached, aborting!

If, like in my case, the given answers do not solve your problem, make sure you're not accidentally doing something along the lines of the following simplified situation:

function foo(){
    // Do something
    bar();
}

function bar(){
    // Do something else
    foo();
}

In this case, even if you set ini_set('xdebug.max_nesting_level', 9999); it will still print out the same error message in your logs.

Answer 18

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.

Answer 19

我在安装许多插件时出现错误所以错误 100 显示包括我安装的最后一个插件的位置 C:\\wamp\\www\\mysite\\wp-content\\plugins\\"..." 所以我删除了这个插件C：驱动器上的文件夹然后一切都恢复正常。我想我必须限制我安装或激活的插件数量。祝你好运，我希望它有帮助

Answer 20

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.

Answer 21

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

Answer 22

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

This way, Xdebug will still behave normally: limit recursion depth in var_dump and so on. As this is a smarty problem, not a Xdebug one!

Answer 23

I had the same problem and I resolved it like this:

• Open MySQL my.ini file
• In [mysqld] section, add the following line: innodb_force_recovery = 1
• Save the file and try starting MySQL
• Remove that line which you just added and Save