Having the same issue on a fresh install of laravel 5 and latest vagrant/homestead env. Haven't tried it on forge yet.

Like others it revolves around commands and sending emails in commands. I guess I'll just have to up the limit - but I'm not a big fan of this at all because it doesn't feel like I'm fixing the problem.

I had this issue on a fresh Forge server the other day (also just upped the limit until a better solution comes up).

Annnnnnnd dealing with the same issue again. Please, can someone address this? Really bothersome.

Same again for me on a fresh Forge server when working with queues. Very annoying

Same here. It happens specifically when I call a model scope.

Happening here as well. It seems to be middleware with magic-method relationship calls which triggers it, for me.

Yes, increasing the xdebug nesting limit "fixes" it, but like others have said, that "fix" smells horrible...

Just a heads up!

This is not a bug in Laravel, Symfony or anything else. It only occurs when XDebug is installed.

It happens simply because 100 or more functions are called recursively. This is not a high figure as such and later versions of XDebug (>= 2.3.0) have raised this limit to 256. See here:

http://bugs.xdebug.org/bug_view_page.php?bug_id=00001100

EDIT: In fact the latest Homestead provisioning script already sets the limit to 250. See line 122 here:

https://github.com/laravel/settler/blob/master/scripts/provision.sh#L122

@sitesense thanks for the heads up. I feel better about the devs at xdebug and Laravel deciding this value needed to be raised rather than a bunch of us raising it ourselves as a temp fix. My main concern was that most of the forum posts about this issue were related to swiftmailer and that the issue was actually with swiftmailer but I know these devs would take that into consideration and only raise the limit if it actually needed to be raised.

Can anyone explain why 100 functions or more are running when I am simply trying to send an email in a queued command? And why this doesn't happen outside of a command? Or why this wasn't a problem in ~4.2 with queue jobs?

Something smells very fishy. Personally I have stability concerns with my first L5 project when it reaches production.

@opheliadesign the many function calls is probably inherent in OOP design with all of the dependencies. You are continually calling parents of parents of parents.

I wouldn't worry that it didn't happen in L4.2 - for all you know, it may have got to 99 recursive function calls itself and just didn't trigger the XDebug limit.

Since XDebug themselves have realised the limit is too low and changed it, it appears that it's just the way things are headed.

Also it's not just Laravel that has this "problem", it's widespread. Take a look at this Symfony issue:

https://github.com/symfony/symfony/issues/13998

Well, looks like the dependency graph is deep enough to reach the limit of 100. 100 nested calls is pretty easy to reach when dealing with recursive structures

and...

Setting xdebug.max_nesting_level = 112 works with the 2.6.5 version (111 fails). With the previous 2.6.4 I can get away with max_nesting_level = 91 (90 fails). So the new version increases the nesting by 21 levels for this particular case, or about 20%.

So it looks like it's the changes in Symfony that have caused the increase.

Of course you could have researched this yourself if it really bothered you that much ;-P

I am having same challenge after I upgraded to LV 5.1 , however it seems this issue occurs when you trying injecting a class event handler constructor method like so:

public function __construct(EmailNotifierInterface $mailer)
    {

        $this->emailNotifier = $mailer;

    }

When I remove __construct() method all works again

@digitlimit if you have the exact same error as the thread title - "L5 Maximum function nesting level of '100' reached, aborting!" - then you are either not using Homestead (or are using an older version of it) or you have a custom server stack and have not updated the 'max_nesting_level' to current recommendations.

// file 20-xdebug.ini
xdebug.max_nesting_level = 250

It is not bug, it is xdebug feature. If code goes through 100 function calls debugger just dies. And Laravel is build that way, you can easy get more than 100 function calls in one request.

Hi all,

A heads up for anyone pushing to Forge with Laravel 5.1.

I had a similar issue on Forge after a 5.1 upgrade. Changing the php.ini with the setting above fixed it on there as well. I suppose for newer servers it won't be an issue.

@sitesense am using Homestead but not sure if its old or latest. I will check xdebug.max_nesting_level limit, Am only worried because I thought am doing something wrong.

Am also worried about the effect this will have on performance.

Am not getting exactly same error message, mine is:

      FatalErrorException in ClassLoader.php line 347:
     Maximum function nesting level of '100' reached, aborting!
     in ClassLoader.php line 347
     at FatalErrorException->__construct() in HandleExceptions.php line 127
     at HandleExceptions->fatalExceptionFromError() in HandleExceptions.php line 112
     at HandleExceptions->handleShutdown() in HandleExceptions.php line 0
     at ClassLoader->findFileWithExtension() in ClassLoader.php line 329
     at ClassLoader->findFile() in ClassLoader.php line 300
     at ClassLoader->loadClass() in ClassLoader.php line 0
     at spl_autoload_call() in ClassLoader.php line 6
     in ClassLoader.php line 412
     at Composer\Autoload\includeFile() in ClassLoader.php line 301
     at ClassLoader->loadClass() in Container.php line 0
     at spl_autoload_call() in Container.php line 736
     at ReflectionClass->__construct() in Container.php line 736

@digitlimit: It's recommended to have NOT xdebug running on a production system because it has a negative impact on performance

@pixelpeter thanks.

I fixed this my add this line to bootstrap/autoload.php in LV 5.1

ini_set('xdebug.max_nesting_level', 120);

.........

define('LARAVEL_START', microtime(true));

I too just hit this limit and it's purely how L5 wants things done that causes this. So many lookups and stuff going on. Must be an insane amount of calls within the framework. Must this not affect performance, in any way? At least require more memory, which in the end would still require more performance. Laravel might not always been about performance, but this is the only thing that really made me question the upgrade from 4.2 to 5.1 on a very large booking system I'm currently "upgrading" to 5.1.

Using the suggestion from @robmazur I too found that my issue was due to the Clockwork service Provider. After disabling it seemed to work. Pity because I use that plugin a ton in development.

@CedNet you must have missed the part that describes how Laravel's dependency injection is a Symfony thing and the increase in function calls is relative to Symfony changes.

So this is no bug? I tried setting the value to 5000, and still got the error. Now tried 1 million, and got 502 Bad Gateway.

I got this error too and am using a Listener which implements ShouldQueue.

I get the error when I was using QUEUE_DRIVER=sync When I switch to QUEUE_DRIVER=beanstalkd the issue goes away.

If I change the Listener to remove the ShouldQueue then the error goes away too even when using QUEUE_DRIVER=sync

This doesn't solve the issue but may help in making decisions. We use beanstalk in Staging and Production so I am not too worried about it now that I know about this.

It's xDebug, turn it off.

I am testing form submission.

I created a custom Request used in the controller.

class RegistrationController extends Controller
{
    public function store(RegistrationFormRequest $request) {

    }
}

The following also results in the same PHPUnit error:

class RegistrationController extends Controller
{
    public function store(Request $request) {

    }
}

However, the following does not result in error:

class RegistrationController extends Controller
{
    public function store() {
        $request = \Request::all();
        ...

    }
}

Just in case someone is actually paying attention to this thread on the team. Because, while it may be an xDebug issue - there may also be an unknown performance hit being caused by this sort of thing.

Cheers.

Ran into this myself. Live Laravel Forge environment. I wasn't aware that xdebug was enabled.

From this thread I understand that I can manually add xdebug.max_nesting_level = 250 to 20-xdebug.ini (Which is server wide, right?)

But, I'd rather disable it in production. Though, I'm not sure how one do that on a Forge server.

(Side note, is it possible to control this per-site instead of per server?)

Hm.. Just came across this thread where Jeffery Way suggest it's not an xdebug issue, but a regression: https://laracasts.com/forum/?p=2309-fatal-error-tests-not-finished-maximum-function-nesting-level-o/0

Anyone got some input on that?

I fixed mine by increasing xdebug.max_nesting_level to 200, by adding the line below to bootstrap/autoload.php in Laravel 5.2

ini_set('xdebug.max_nesting_level', 200);

I got the same on my php localhost,

Are you all using the default auth stuff in Laravel? It seems like this only happens, at least for me, when your routes are after the Route::auth().

Route::auth();
Route::get('/home', 'HomeController@index');

I correct this by adding the following in my "auth'd" controllers...

    public function __construct()
    {
        $this->middleware('auth');
    }

Example...

class HomeController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');
    }

    public function index()
    {
        return view('home');
    }
}

This issue does not appear for me when using PHP 7, but when I use PHP 5.6, it always happens

Add this ini_set('xdebug.max_nesting_level', 2000); in your project name/bootstrap/autoload.php if not working then increase the number.