Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

ProudOne's avatar

Interpreting a Stack Trace

I'm building a simple admin dashboard with Laravel 8, running it in a docker container. Whenever there's an exception of any kind, the page locks up for ~10 seconds, then dumps a massive stack trace that seems to indicate that PHP has run out of memory (while attempting to report the error?).

I've tried disabling my custom exception handler and saw no change. I've tried stepping through via XDebug, but it simply disconnects without anything helpful once the memory overflow happens.

I've tried upgrading all packages to make sure that it isn't a previously fixed bug... no dice.

I've also generated an XDebug Trace which ended up taking ~20GB uncompressed and showed nothing that made sense to me. In KCachegrind, the largest amount of memory displayed doesn't even come close to the limit that PHP reports crashing at.

At this point I'm stumped. If you have an idea on how to diagnose this further, please let me know.

Here's the full stack trace of an error resulting from me forgetting an href attribute on a button component: https://gist.github.com/ProudOne/b7ed01fa87ee45660de8ba2a1f45c7a0

Edit: Just to clarify; I know that in the stack trace above, I've got a missing HREF in a button component. It's the fact that php runs out of memory (1GB!!) afterward, presumably while processing that error, that has me stumped.

Memory runs out here: https://gist.github.com/ProudOne/b7ed01fa87ee45660de8ba2a1f45c7a0#file-gistfile1-txt-L73

0 likes
7 replies
Tray2's avatar

Nobody is ever going to spend time trying to read that gist. You need to make it readable for anyone to even try.

But take a look at this line

srv/app/vendor/facade/ignition/src/Views/E in /srv/app/resources/views/components/button.blade.php on line 4

1 like
ProudOne's avatar

@Tray2 I changed the link to a non-wrapped view - Good call. As for the line you're calling out, yes, I know where the original exception originates, but this happens for literally any exception in the app. PHP always runs out of memory reporting any error or exception. It's a pain to develop that way, because it takes ~10s to reload the page if you've accidentally a word - and I sure can't deploy like this.

Tray2's avatar

@ProudOne Why have you changed the exception handling to your own?

When you deploy you turn off debug and set the app_env to prod, then it just logs the errors, and doesn't show them.

ProudOne's avatar

@Tray2

  1. Because I integrate Sentry.
  2. Logging the errors generates the same stack puke.
ProudOne's avatar

@Sinnbeck According to Sentry's own documentation, altering the handler is very much necessary: https://docs.sentry.io/platforms/php/guides/laravel/ As I had mentioned in my OP, the problem persists even if I comment out literally everything in Handler.php other than the class definition itself.

I've been messing around with the code since starting the thread tough, and it looks like this only happens when the error is related to a view.

Facade\Ignition\Views\Engines\CompilerEngine->handleViewException($baseException = class ErrorException { protected $message = 'Undefined variable: href'; private ${Exception}string =

Please or to participate in this conversation.