Maximum function nesting level of '100' reached

Please try again after raising xdebug.max_nesting_level to 500 or so.

And/or please try with xdebug disabled altogether.

Depending on the results, this might be not a bug, a major bug, or stay critical.

You have xdebug enabled and are doing a var_dump() or print_r(). Disable xdebug or reconfigure xdebug to either allow deeper nesting, or to not override the output of those functions.

For those who want more specific instructions, https://www.drupal.org/node/2158467#comment-9473799

Just to be clear, this happens during regular site operation (no need to have a var_dump or print_r). Simply enable xdebug with the default nesting value (100) and visit node/add/article on a fresh installation of Drupal 8 using the standard install profile and you'll run into this.

Note: xdebug 2.3 got released, which changed the default value to 256, see http://xdebug.org/index.php

Looking at this I think we need to at least do something. How about adding something to the system report page to help users if xdebug is enabled.

Looking at this I think we need to at least do something. How about adding something to the system report page to help users if xdebug is enabled.

I like the idea. Given that this page should be quite small, it should be able to access that page.

After discussing this with alexpott I've created a patch to report on this on the system report page.

I think this is important since many first time users are likely to hit this issue, xdebug is enabled by default on MAMP for example, but doesn't yet use 2.3 which has a decent limit of 256. It's best to guide users on how to resolve this rather than let them google it. This fix will also report on where that ini file is. Admittedly that doesn't work for MAMP which you need to edit the php.ini in a different way (I can add a note on this if it's felt to be important).

This is the first time I've contributed a patch, so I tried to follow the instructions on drupal.org, please do let me know if I've got anything wrong :)

For example, when I ran:

git diff 8.0.0-beta7 > patchfile.txt

It included things I haven't changed such as the composer.lock file.

So I created the patch based on

git diff 46ff3d51c58cd78e31c708cb1290446094fb0bdc > patchfile.txt

That was the last commit before my commit. I hope this is correct.

It also wasn't totally clear how to name the patch from the instructions on point 11 at https://www.drupal.org/node/707484 - however, the dreditor plugin was very helpful and I used its suggestion!

changing status to needs review

git diff 8.0.0-beta7 > patchfile.txt

You had luck, your patch worked, but usually you should checkout 8.0.x and compare the code against that.

1. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +  if (function_exists('xdebug_enable') && ini_get('xdebug.max_nesting_level') < 256) {
   

   Feel free to use http://php.net/manual/en/function.extension-loaded.php instead, seems to be a bit more specific of what is going on.

2. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +    // Report on where correct ini file is to user
   +    $iniLocation = false;
   +    $iniScannedFiles = php_ini_scanned_files();
   +    if ($iniScannedFiles !== false) {
   +      $iniFiles = explode(',', php_ini_scanned_files());
   +      foreach ($iniFiles as $value) {
   +        if (strpos($value, 'xdebug.ini') !== false) {
   +          $iniLocation = trim($value);
   +          break;
   +        }
   +      }
   +    }
   +
   

   Nice idea to show the correct php.ini. Note: We don't use camel case for local variables, see https://www.drupal.org/coding-standards

3. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +    $description = 'A max_nesting_level lower than 256 will cause issues with Drupal. To fix this set <em>xdebug.max_nesting_level=256</em> in your PHP configuration for Xdebug';
   +    if ($iniLocation) {
   +      $description = t($description . ' in <em>@iniLocation</em>', array('@iniLocation' => $iniLocation));
   +    } else {
   +      $description = t($description);
   +    }
   

   Note: In order to allow Potx to scan the available strings we can't use variables as part of a t() string. As a result you could hardcode the $description into the two different t() calls.

   The text is a bit misleading, its not required to have a limit of 256, its just higher than 100.

many thanks for the feedback, will amend and will repost a patch.

The suggested limit of 256 is simply because that is the new default in Xdebug 2.3. From this thread (and my initial testing) its not apparent what the ideal value really is, but anything above 200 seems to work just fine and seems a more sensible, practical suggestion. I could note this value is the recommended setting.

Thanks for the coding standard tips. I'll assign this to me while working on it

Uploaded new patch with suggested fixes.

As suggested patch created with:

git diff 8.0.x > maximum_function-2393531-13.patch

Functionally this works perfectly. I like it. I've made a couple of minor fixes to the comments to keep them in line with Drupal coding standards:

1. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +  // Check whether xdebug.max_nesting_level is below 256 since if so, will cause issues
   

   This line is over 80 characters long, and doesn't end with a full stop.

2. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +    // Report on where correct ini file is to user
   

   This comment needs to end in a full stop.

New patch attached.

thanks for the feedback mrjmd, very helpful for someone new to contributing to Drupal. Will make sure I use Codesniffer in future!

1. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +    $ini_location = false;
   ...
   +    if (!$ini_location) {
   +      $ini_location = php_ini_loaded_file();
   +    }
   

   Could set this to php_ini_loaded_file() instead of false (btw the Drupal coding standard is FALSE) and remove the if completely.

2. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +    if ($ini_location !== false) {
   

   !== FALSE

3. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +      $description = t('A max_nesting_level lower than 256 will cause issues with Drupal. To fix this it is recommended to set <em>xdebug.max_nesting_level=256</em> in your PHP configuration for Xdebug in <em>@iniLocation</em>', array('@iniLocation' => $ini_location));
   

   If the placeholder is %ini_location then you don't need the <em> tag around @iniLocation

4. +++ b/core/modules/system/system.install
   @@ -633,6 +633,42 @@ function system_requirements($phase) {
   +      'value' => t('xdebug.max_nesting_level set to @value', array('@value' => ini_get('xdebug.max_nesting_level'))),
   

   Should use the %value since this will wrap it with an <em>. Also this is a sentence so should end with a fullstop.

+    $requirements['xdebug_max_nesting_level'] = array(
+      'title' => t('Xdebug Settings'),
+      'value' => t('xdebug.max_nesting_level set to @value', array('@value' => ini_get('xdebug.max_nesting_level'))),
+      'description' => $description,
+      'severity' => REQUIREMENT_ERROR,
+    );

"Xdebug Settings" => "Xdebug settings"

Also, should this really be a REQUIREMENT_ERROR, rather than just a REQUIREMENT_WARNING? I'm not sure we want to prevent people from, say, installing Drupal just because of this (especially because I strongly suspect that you don't need to go all the way up to 256 for most sites to work in practice).

+++ b/core/modules/system/system.install
@@ -633,6 +633,42 @@ function system_requirements($phase) {
+      'value' => t('xdebug.max_nesting_level set to @value', array('@value' => ini_get('xdebug.max_nesting_level'))),

Should use the %value since this will wrap it with an <em>. Also this is a sentence so should end with a fullstop.

It's not a sentence currently (would be if the word "is" gets added).

A better way might be to just make the title "Xdebug maximum nesting level" rather than "Xdebug settings", and then just use the actual number for the 'value', no words necessary....

+      $description = t('A max_nesting_level lower than 256 will cause issues with Drupal. To fix this it is recommended to set <em>xdebug.max_nesting_level=256</em> in your PHP configuration for Xdebug in <em>@iniLocation</em>', array('@iniLocation' => $ini_location));
....
+      $description = t('A max_nesting_level lower than 256 will cause issues with Drupal. To fix this it is recommended to set <em>xdebug.max_nesting_level=256</em> in your PHP configuration for Xdebug');

Might be useful to expand a bit on what "issues with Drupal" means. Basically we are saying that certain pages on the site might crash/whitescreen if the max_nesting_level setting is too low.

Updated patch with all the fixes from #17, and most of #18.

A few things may remain:

1. REQUIREMENT_ERROR or REQUIREMENT_WARNING, I agree with @David_Rothstein that a warning is sufficient, let's see what others think.

2. Regarding this:

A better way might be to just make the title "Xdebug maximum nesting level" rather than "Xdebug settings", and then just use the actual number for the 'value', no words necessary....

I tried it the way suggested here, but it does not really look good or stay consistent with other such errors (screenshots attached). So I've added the "is" and full stop to make it a proper sentence.

3. I've expanded the "will cause issues with Drupal" part, but I'm still not sure if this is the best wording. Thoughts?

Screenshot with proposed fix from #18:

Screenshot of the warning the way this patch does it:

Oops, errant string in there (interdiff above is correct).

Looks better to me now, although still needs "Xdebug Settings" => "Xdebug settings" and "false" => "FALSE".

I am curious what others think about REQUIREMENT_ERROR vs. REQUIREMENT_WARNING also.

+  // Check if xdebug.max_nesting_level is below 256, as that will cause issues.
+  // @see https://www.drupal.org/node/2393531

Just noticed this; I'm not sure the @see is correct there according to documentation standards (I think it might be reserved for PHPDoc at the top of a function only). Could change it to "See", or maybe just remove? (Not sure there's a whole lot of useful information in this issue that isn't contained in the patch/code itself.)

The REQUIREMENT_ERROR vs REQUIREMENT_WARNING is tricky. If it is set to the default 100 then with standard installed certain pages are be broken. Given that this requirement only exists when xdebug is on I think I prefer REQUIREMENT_ERROR.

Okay, I think this resolves the remaining issues. I got rid of the reference in the comment back to this issue, and updated the comment itself to reflect the changes made in the last patch.

What about adding the following line to Drupal's default .htaccess:
php_value xdebug.max_nesting_level 256

It also fixes the problem for 99.9% of the users that have xdebug enabled, and it's harmless to the 99.9% that don't.

This happened to me today as well.

I also faced the same issue.
Below is the solution.

Maximum function nesting level of '100' reached, aborting

You could run into this error if you have the XDebug extension installed and
you execute a lot of requests in callbacks. This error message comes
specifically from the XDebug extension. PHP itself does not have a function
nesting limit. Change this setting in your php.ini to increase the limit::

xdebug.max_nesting_level = 1000

After this please restart your apache server.
Note I faced this problem while working in Drupal 8.
It solved my problem, hope this will helps.

Patch works for a warning on install. Can we also add a warning on admin/reports/status?

I've updated the docs at https://www.drupal.org/requirements/php to hopefully help others find this workaround.

akalata. I don't understand. The patch does add a warning in admin/reports/status as wel..

Upgrading the patch a little bit with the following enhancements:

1. Solving the problem to the 99% by configuring the max nesting level in .htaccess
2. Making it easier for translators in the future by removing the text duplication and by moving the '256' value to a variable that can easily be modified without invalidating the translation.

I'd like to also bump this to major as this severely breaks Drupal the moment that someone installs Xdebug.

Instructions to reviewers (running Apache, if you run nginx, you'll need to modify the xdebug.ini file instead of the .htaccess):
1. Apply the patch. Make sure your D8 site works.
2. Enable Xdebug (see http://wylbur.us/2014-06-17-add-xdebug-to-ubuntu-1404 if you're running Ubuntu)
3. Modify the .htaccess file and comment the xdebug.max_nesting_level line. Your D8 site may now be broken.
4. Uncomment the line and set the value to something usable, but less than 256, I suggest 200. Verify that your D8 site works, and that an error message appears correctly in admin/reports/status
5. Finally, set the value again to 256. Verify that the error message disappears.

Steps to review 1-3 may vary, depending on which version of xdebug you're running. I recommend using node/add/page as the indicator of whether the "D8 site works" or not. After modifying the .htaccess in Drupal's root (not other .htaccess files that Drupal adds), be sure to clear caches.

Overall, I think this works well - changes the value automatically, intermediate values (200-ish) result in an error message in admin/reports/status, and setting to the default 100 triggers the error we're looking to fix.

My only question is whether it's acceptable to automatically override xdebug.max_nesting_level in .htaccess? This would be a question for a core maintainer.

@akalata i think you're right - I'm not convinced it is. I think it's great to have the warning but setting the value means that people can't set it to be higher.

@alexpott they can set the variable in the .htaccess configuration; then again, thinking about other warnings (PHP memory_limit for image toolkits, for example) don't change values, but recommend that values be changed. Perhaps we should go with that standard approach?

@jcnventura, I like your idea of coding for the 99%, but I don't know how many "regular" users would have xdebug enabled?

@alexpott honestly, if people do need more than 256 levels of recursion, they're simply doing something really wrong.. The fact that Drupal 8 breaks with the default value (100), is already a sign that we need to take a look if this huge call stack is justified.

Anyway, it seems the consensus is that changing .htaccess should not be done, so I'm re-rolling the patch without that change.

@jcnventura the xdebug author has recently raised the default to 256.

Some minor standards, docs, and UI text points below, otherwise I would have RTBC'd.

1. +++ b/core/modules/system/system.install
   @@ -648,6 +648,36 @@ function system_requirements($phase) {
   +    // Report on where correct ini file is to user.
   

   This could probably use some more words, it's pretty terse. "Report on where the correct ini file is to the user." would be more friendly :)

2. +++ b/core/modules/system/system.install
   @@ -648,6 +648,36 @@ function system_requirements($phase) {
   +    if ($ini_scanned_files !== false) {
   

   Minor: This should be FALSE per https://www.drupal.org/coding-standards#naming.

3. +++ b/core/modules/system/system.install
   @@ -648,6 +648,36 @@ function system_requirements($phase) {
   +      $description .= ' ' . t('Your Xdebug configuration is located in @iniLocation.', array('@iniLocation' => $ini_location));
   

   I don't want to get caught up on this but isn't it possible that this will just give the path to "php.ini" if it doesn't find a specific file for Xdebug? $ini_location = php_ini_loaded_file(); In which case wording along the lines of "Your Xdebug configuration can be modified in @iniLocation" might make more sense?

Thanks @Cottser for the detailed review.

Patch works great and as expected. I would RTBC, but just 2 extremely minor things (that might actually be just my taste, please chime in):

1. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +    $description = t('A max_nesting_level lower than @lvl will cause some pages in your Drupal site to crash. To fix this it is recommended to set xdebug.max_nesting_level=@lvl in your PHP configuration for Xdebug.', array('@lvl' => $xdebug_nesting_level));
   

   @lvl => @level? These texts are translated by a lot of translators, I feel it is polite to make it as easy to read and type as possible,

2. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +      $description .= ' ' . t('Your Xdebug configuration can be modified in @iniLocation.', array('@iniLocation' => $ini_location));
   

   Should we not use the same casing of variables inside translatable strings as php variables casing? Like use @ini_location also there?

Other thoughs?

I agree with #43.

Yeah, I wasn't sure about those either, and if it's not just me then let's change 'em.

Nice!

I call BS, Drupal\page_cache\Tests\PageCacheTest.

See friends solution still didn't solve the problem, so I will go to the directory below the module views folder deleted, directly to the page can display properly。

1. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +  $xdebug_nesting_level = 256;
   

   Let's add an inline comment above this explaining why we picked 256 (explained earlier on the issue), with a link to a reference if available. (See #6 and #13.)

2. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +  // Check if xdebug.max_nesting_level is too low, as it crashes some pages.
   

   How about:

   Check xdebug.max_nesting_level, as some pages will not work if it is too low.

3. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +  if (extension_loaded('xdebug') && ini_get('xdebug.max_nesting_level') < $xdebug_nesting_level) {
   ...
   +      'value' => t('xdebug.max_nesting_level is set to %value.', array('%value' => ini_get('xdebug.max_nesting_level'))),
   

   Minor, but we're calling the same ini_get() twice. Store it to a variable?

4. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +    // Report on where the correct ini file is to the user.
   

   This hunk isn't actually reporting anything to the user. Maybe:

   Locate the correct ini file for Xdebug.

5. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +    if ($ini_scanned_files !== FALSE) {
   

   I had to parse this code in my head to understand it. Maybe add an inline comment above this line:

   If there is a specific ini file for Xdebug, recommend that in place of the loaded ini file.

6. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +    $description = t('A max_nesting_level lower than @level will cause some pages in your Drupal site to crash. To fix this it is recommended to set xdebug.max_nesting_level=@level in your PHP configuration for Xdebug.', array('@level' => $xdebug_nesting_level));
   

   We're burying the lead here as to what a max_nesting_level is, and there are some unneeded words in this that make it harder to read. ("To fix this it is recommended to..." in particular.) Also "crash" is a bit dramatic. Maybe as little as:

   Set xdebug_.max_nesting_level=@level in your PHP configuration as some pages in your Drupal site will not work when this setting is too low.

   Or something; maybe someone else can come up with a better wording that is more concise. :)

7. +++ b/core/modules/system/system.install
   @@ -648,6 +648,35 @@ function system_requirements($phase) {
   +      'severity' => REQUIREMENT_ERROR,
   

   FWIW @alexpott's reason for making this a REQUIREMENT_ERROR makes sense to me, so +1.

I also updated the summary as "Fix it" is not really informative. :)

With xjm's suggestions..

Since I already RTBCd this, I think it still looks good. :)

Good points from xjm and I see the new patch takes them all into account.

+++ b/core/modules/system/system.install
@@ -648,6 +648,44 @@ function system_requirements($phase) {
+      $description = t('Set xdebug_.max_nesting_level=@level in your PHP configuration as some pages in your Drupal site will not work when this setting is too low.', array('@level' => $minimum_nesting_level));

Looks like a stray underscore got into the setting name: 'xdebug_.max_nesting_level' :)

Indeed, great catch @amateescu :)

+++ b/core/modules/system/system.install
@@ -648,6 +648,44 @@ function system_requirements($phase) {
+      // Locate the correct ini file for Xdebug.
+      $ini_scanned_files = php_ini_scanned_files();
+      $ini_location = php_ini_loaded_file();
+      // If there is a specific ini file for Xdebug, recommend that in place of
+      // the loaded ini file.
+      if ($ini_scanned_files !== FALSE) {
+        $ini_files = explode(',', $ini_scanned_files);
+        foreach ($ini_files as $value) {
+          if (strpos($value, 'xdebug.ini') !== FALSE) {
+            $ini_location = trim($value);
+            break;
+          }
+        }
+      }
+
+      $description = t('Set xdebug.max_nesting_level=@level in your PHP configuration as some pages in your Drupal site will not work when this setting is too low.', array('@level' => $minimum_nesting_level));
+      if ($ini_location !== FALSE) {
+        $description .= ' ' . t('Your Xdebug configuration can be modified in @ini_location.', array('@ini_location' => $ini_location));
+      }

This doesn't really match the existing php.ini related requirements. For example:

Your server is capable of displaying file upload progress through APC, but it is not enabled. Add apc.rfc1867 = 1 to your php.ini configuration. Alternatively, it is recommended to use <a href="@url">PECL uploadprogress</a>, which supports more than one simultaneous upload.

and

Multibyte string function overloading in PHP is active and must be disabled. Check the php.ini <em>mbstring.func_overload</em> setting. Please refer to the <a href="@url">PHP mbstring documentation</a> for more information.

I guess it could be viewed as helpful to add the ini location but I also think it might be quite fragile. For example, I use http://php-osx.liip.ch/ to manage multiple PHP versions. It has the following ini file structure...

Loaded Configuration File => /usr/local/php5/lib/php.ini
Scan this dir for additional .ini files => /usr/local/php5/php.d
Additional .ini files parsed => /usr/local/php5/php.d/10-extension_dir.ini,
/usr/local/php5/php.d/20-extension-opcache.ini,
/usr/local/php5/php.d/50-extension-apcu.ini,
/usr/local/php5/php.d/50-extension-blackfireio.ini,
/usr/local/php5/php.d/50-extension-curl.ini,
/usr/local/php5/php.d/50-extension-gmp.ini,
/usr/local/php5/php.d/50-extension-igbinary.ini,
/usr/local/php5/php.d/50-extension-imap.ini,
/usr/local/php5/php.d/50-extension-intl.ini,
/usr/local/php5/php.d/50-extension-mcrypt.ini,
/usr/local/php5/php.d/50-extension-memcache.ini,
/usr/local/php5/php.d/50-extension-memcached.ini,
/usr/local/php5/php.d/50-extension-mongo.ini,
/usr/local/php5/php.d/50-extension-mssql.ini,
/usr/local/php5/php.d/50-extension-oauth.ini,
/usr/local/php5/php.d/50-extension-pdo_dblib.ini,
/usr/local/php5/php.d/50-extension-pdo_pgsql.ini,
/usr/local/php5/php.d/50-extension-pgsql.ini,
/usr/local/php5/php.d/50-extension-propro.ini,
/usr/local/php5/php.d/50-extension-raphf.ini,
/usr/local/php5/php.d/50-extension-readline.ini,
/usr/local/php5/php.d/50-extension-redis.ini,
/usr/local/php5/php.d/50-extension-solr.ini,
/usr/local/php5/php.d/50-extension-ssh2.ini,
/usr/local/php5/php.d/50-extension-twig.ini,
/usr/local/php5/php.d/50-extension-uploadprogress.ini,
/usr/local/php5/php.d/50-extension-xdebug.ini,
/usr/local/php5/php.d/50-extension-xhprof.ini,
/usr/local/php5/php.d/50-extension-xsl.ini,
/usr/local/php5/php.d/60-extension-pecl_http.ini,
/usr/local/php5/php.d/99-liip-developer.ini

It is possible that I (or they) could have overridden xdebug.max_nesting_level in /usr/local/php5/php.d/99-liip-developer.ini and then adding the value to /usr/local/php5/php.d/50-extension-xdebug.ini would make no difference. Personally I'm not sure that the complexity is worth it.

+++ b/core/modules/system/system.install
@@ -648,6 +648,44 @@ function system_requirements($phase) {
+      $description = t('Set xdebug.max_nesting_level=@level in your PHP configuration as some pages in your Drupal site will not work when this setting is too low.', array('@level' => $minimum_nesting_level));

xdebug.max_nesting_level=@level should be wrapped with

</pre> tags as per apc requirements in <code>file_requirements()

OK. Removing the ini file guess, and adding <code> tags as per file_requirements().

I've also changed to short array syntax, which is why the interdiff has a few more changes.

I've tested and reviewed this patch. I've confirmed when set to 256 installation works and when lower, requirements alert below shows up:

I'm marking this RTBC. The only thing this won't resolve though is if Drupal is already installed when xdebug is configured. Then it throws the same error, but I think this is sufficient to warn on install.

Why, oh why does everyone think this only works on install? See my reply in #30:

The patch does add a warning in admin/reports/status as well..

Thanks for the RTBC...

Committed 1199955 and pushed to 8.0.x. Thanks!

Add these lines in php.ini under path \wamp\bin\apache\apache2.4.9\bin and restart the Wamp

[xdebug]
xdebug.remote_enable = Off
xdebug.profiler_enable = off
xdebug.profiler_enable_trigger = Off
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir = "C:/wamp/tmp"
xdebug.show_local_vars=0
xdebug.max_nesting_level=256

Thanks,
Worked for me

If you are still experiencing this error with a maximum nesting level of 100, you are running a version of Xdebug that is over a year old and that should be upgraded to a newer version.