Form - Fatal Exception Maximum function nesting level of '100' reached - 2.2.0-RC2

[chrisben]

Using latest Standard Symfony 2.2.0 RC2.

The page I display is a simple form created from an abstract type containing a collection of another abstract type which contains only a date entry in a choice widget:

$builder->add('myDate', 'date', array('widget' => 'choice', 'format' => \IntlDateFormatter::LONG, 'years' => range( date('Y'), date('Y') + 5 )))

When displaying this form I get the following exception:

Error: Maximum function nesting level of '100' reached, aborting! in [...]/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Translation/Translator.php line 143

The stack looks like this (just top part of it ..it's very long)

Translator->trans() in [...]/vendor/symfony/symfony/src/Symfony/Bridge/Twig/Extension/TranslationExtension.php line 93
TranslationExtension->trans() in [...]/app/cache/dev/twig/f8/0b/aad3cdcac9f42ea84c8a80244f11.php line 544
__TwigTemplate_f80baad3cdcac9f42ea84c8a80244f11->block_choice_widget_options() in [...]/app/cache/dev/classes.php line 5945
Twig_Template->displayBlock() in [...]/app/cache/dev/twig/f8/0b/aad3cdcac9f42ea84c8a80244f11.php line 489
__TwigTemplate_f80baad3cdcac9f42ea84c8a80244f11->block_choice_widget_collapsed() in [..]/app/cache/dev/classes.php line 5945
??call_user_func() in [...]/app/cache/dev/classes.php line 5945
Twig_Template->displayBlock() in [...]/app/cache/dev/twig/f8/0b/aad3cdcac9f42ea84c8a80244f11.php line 394
__TwigTemplate_f80baad3cdcac9f42ea84c8a80244f11->block_choice_widget() in [...]/app/cache/dev/classes.php line 5945

This goes on an on for -I suppose- a total of 100 method calls.

It looks like the nesting level here is exactly 100 because if I set this in my app_dev.php:

ini_set('xdebug.max_nesting_level', 101);

Then the form is rendered correctly. Setting this value to 100 (its default apparently) brings this exception.

I only get that problem for a date within a collection. If I remove the date form element and put something else the exception doesn't arise.

[Tobion]

How about you use the search?

[bendavies]

@Tobion responses like that are hardly helpful. You could at least phrase it in a friendly way. This is the kind of response that puts people off open source projects.

[Tobion]

It's a pitty that one has to remind people to use the search before posting something. It's the fundamental thing of the web. And it's not like this issue is hard to find. And then they even complain that the one who gives them the tipp to use Github search or even the new, secret thing called Google, doesn't do the work for them.

[chrisben]

Ok, I didn't find the similar issue #6866 , blame it on me.
I used the search (both google and github) + browsed opened issues and failed to find it. I apologize for being part of the human species. This being said, as @bendavies said, the comment posted by @Tobion was not very helpful.

Now, back to this issue, which really actually was #6864 , it was supposed to be fixed fifteen days ago and merged into 2.2.
So it could be a regression or perhaps the thing never got fixed properly in the first place. I'll link to this issue in that discussion.

[fabpot]

Can you try to raise the max_nesting_level to say 1000 to see if you actually have an infinite recursion? Or even better, can you check that the problem does (not) occur when disabling XDebug?

[chrisben]

Setting max_nesting_level to 1000 does work (=problem does not occur), no infinite loop.
Disabling xdebug also works. If I restart the server with xdebug activated and reload the page, the problem appears.

[fabpot]

So, I'm closing this issue as this is related to the too low value of the xdebug nesting level (unfortunately, the default value of 100 is really too small). Thanks for taking the time to actually validate my guess.

[chrisben]

So would you suggest setting a high value for xdebug.max_nesting_level with ini_set in app_dev.php is the best workaround for my problem?

[fabpot]

Yes, my php.ini has this setting set to 1000.

[alvarezmario]

This issue is also reflected in the Form chapter as a note. It was me the
one who put it there after facing the same problem.. :)

2013/2/20 Fabien Potencier notifications@github.com

Yes, my php.ini has this setting set to 1000.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7112#issuecomment-13859138.

[alvarezmario]

Sorry, it in the Form collections cookbook. Is right above this link: http://symfony.com/doc/current/cookbook/form/form_collections.html#allowing-new-tags-with-the-prototype

[fjugaldev]

Hi guys,

Since a few days, i'm having troubles with my project, i'm having the same problem as mentioned before:

Error: Maximum function nesting level of '200' reached, aborting!
500 Internal Server Error - FatalErrorException

I've tried with everything and i can't solve the problem.

I set the option "xdebug.max_nesting_level" between 200 and 1200 in my php.ini and nothing happened, i'm getting the same error message.

What anything more can i try?, this problem it's taking a long time for me and i need to solve this as soon as possible.

I tried to clear cache via console and manually and again the same error appear. When i use the command "php app/console cache:clear" the output show me the same error:

If exist anything else that i can try, i will being very thankful with you.

Once again, thank you and waiting for some tips or ideas.

By the way, i'm using symfony 2.7.6 and PHP 5.5.12 (Wampserver 2.5 x64)

Greetings,

P.S. Sorry for my bad english. =)

[Tobion]

If you get the same error message it means, you have set it in the wrong php.ini that is not in effect.

[fjugaldev]

Hi Tobion,

Thanks for your time!

The error is the same but with the same value as the php.ini, if i set the value to 1000 the message will display 1000, so i've edited the correct php.ini. It's like a infinite loop or something like.

Hoping some more tips or ideas.

Greetings,

Javier Ugalde

[Tobion]

I don't think its caused by symfony. Otherwise there would be more reports that there is a regression.
It's probably somewhere in your code or a library that you are using. I guess you have to debug that yourself.

[jakzal]

@JavierUgalde you can always prove us wrong by forking the symfony-standard edition and reproducing your issue on a new branch. I'll be happy to check if this is a problem on my environment.