frankenphp frankenphp PHP Fatal error: Allowed memory size of 268435456 bytes exhausted

What happened?

Hi, I am having some problems with frankenphp in workermode.

I am using symfony and followed the instructions from this repo https://github.com/dunglas/symfony-docker to configure frankenphp locally worker mode for my existing symfony project.

I have been using frankenphp locally with worker mode enabled for about 2 weeks now.

How did i come across this issue? First, last week, I noticed that I can not use dd() with worker mode. (Is this also an error or is this by design?) The server always returns an error 500. The only way to use dd() was to disable worker mode or what I did is use dump() and then throw an exception with worker mode on locally. This workaround worked fine for a few days.

1-2 days ago I started having the issue that whenever I use dump() and then throw an exception with worker mode on locally, i see the exception page with the dump message, but when I go to the controller to remove the exception and dump() , the server stops responding.

The message I get from the logs I entered in the textfield below, but essentially it says "frankenphp PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 29364224 bytes)" and lists different php files depending on the situation.

When i disable worker mode locally and I do the same thing, dump() and throw an exception, and then remove the exception, the server works fine.

Before frankenphp, I used the default symfony local server and I didn't have any issues with that one.

Build Type

Docker (Debian Bookworm)

Worker Mode

Yes

Operating System

macOS

CPU Architecture

Apple Silicon

PHP configuration

Relevant log output

There are 2 different cases when I got the error: 

1) 
2025/08/07 15:38:24.012	ERROR	frankenphp	PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 2097160 bytes) in /app/vendor/symfony/var-dumper/Cloner/VarCloner.php on line 178	{"syslog_level": "err"}

github.com/dunglas/frankenphp.go_log

	/go/src/app/frankenphp.go:618

_cgoexp_0b63bd6114d1_go_log

	_cgo_gotypes.go:1460

runtime.cgocallbackg1

	/usr/local/go/src/runtime/cgocall.go:446

runtime.cgocallbackg

	/usr/local/go/src/runtime/cgocall.go:350

runtime.cgocallback

	/usr/local/go/src/runtime/asm_arm64.s:1131


then i increased the memory limit to 256mb and I got the error: 

2025/08/08 18:48:21.605	ERROR	frankenphp	PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 29364224 bytes) in /app/vendor/symfony/http-kernel/Profiler/FileProfilerStorage.php on line 164	{"syslog_level": "err"}

github.com/dunglas/frankenphp.go_log

	/go/src/app/frankenphp.go:618

_cgoexp_cf03a49aedfe_go_log

	_cgo_gotypes.go:1528

runtime.cgocallbackg1

	/usr/local/go/src/runtime/cgocall.go:446

runtime.cgocallbackg

	/usr/local/go/src/runtime/cgocall.go:350

runtime.cgocallback

	/usr/local/go/src/runtime/asm_arm64.s:1131

<br />

<b>Fatal error</b>:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 29364224 bytes) in <b>/app/vendor/symfony/http-kernel/Profiler/FileProfilerStorage.php</b> on line <b>164</b><br />

Aug 08 '25 22:08 frenci8

It sounds like there may be a memory leak somewhere, on the PHP side where things aren’t properly cleaned up on a die'd request. You don’t mention what framework you’re using. However, all of them need to perform some kind of clean-up when the request ends, and a die will just exit the request immediately without giving them a chance to clean up, eventually causing an OOM.

Worker mode is likely not suited for a log-and-die debugging approach. It does work fine with Xdebug however, which allows you to pause execution and inspect variable values.

Aug 08 '25 23:08 withinboredom

It sounds like there may be a memory leak somewhere, on the PHP side where things aren’t properly cleaned up on a die'd request. You don’t mention what framework you’re using. However, all of them need to perform some kind of clean-up when the request ends, and a die will just exit the request immediately without giving them a chance to clean up, eventually causing an OOM.

Worker mode is likely not suited for a log-and-die debugging approach. It does work fine with Xdebug however, which allows you to pause execution and inspect variable values.

I am using symfony. I mentioned that in the original thread.

I am not using die() or dd().

My problem is with the "Allowed memory size" error. Why does it happen that when there is a memory limit error the server stops responding and I have to restart the docker container in order to visit the website again? This was not an issue until a couple days ago. What if this error happens on prod, do I restart the container there too like i do locally? Is that the solution?

Aug 08 '25 23:08 frenci8

Thanks for the clarification. I see there are multiple issues being discussed here, so let me address them separately:

The dd() behaviour

In your original issue, you noted that dd() doesn’t work with worker mode and returns a 500 error.

The memory leak

You mention there is a memory exhaustion in your logs. You were not clear whether that was caused by dd() or dump() and throw.

In any case, can you provide a reproducer for us to test this?

Aug 09 '25 00:08 withinboredom

Thanks for the clarification. I see there are multiple issues being discussed here, so let me address them separately:

The dd() behaviour

In your original issue, you noted that dd() doesn’t work with worker mode and returns a 500 error.

The memory leak

You mention there is a memory exhaustion in your logs. You were not clear whether that was caused by dd() or dump() and throw.

In any case, can you provide a reproducer for us to test this?

yes, that is correct.
That was because of dump() + throw exception. The problem isn't the memory exhaustion error, it is that the server doesn't respond anymore and I have to restart the docker container so I can visit the website again. This happens only with worker mode on. With worker mode off, I still get the memory exhaustion error, but if I visit any other url, everything works fine without needing to restart the docker container.

I increased the memory limit to 2gb and I do not get the memory exhausted error anymore, but my question is, the fact that I have to restart the container again, is that an issue with me only or with frankenphp?

I will check if I can reproduce the error in a new repo and link it.

Aug 09 '25 02:08 frenci8

I increased the memory limit to 2gb and I do not get the memory exhausted error anymore

Could it be that your exception trace is huge, or you’re dumping doctrine objects (those things are massive as doctrine will try to render your entire database depending on how you have things set up)? Maybe try setting zend.exception_ignore_args in your php.ini file? (This is turned on with the production ini file that comes with php. IIRC)

the fact that I have to restart the container again, is that an issue with me only or with frankenphp?

It is unusual and might be an issue with PHP, the worker script, or FrankenPHP. It is hard to say without being able to step through the code and seeing what it is actually doing when it is frozen.

Aug 09 '25 09:08 withinboredom

I increased the memory limit to 2gb and I do not get the memory exhausted error anymore

Could it be that your exception trace is huge, or you’re dumping doctrine objects (those things are massive as doctrine will try to render your entire database depending on how you have things set up)? Maybe try setting zend.exception_ignore_args in your php.ini file? (This is turned on with the production ini file that comes with php. IIRC)

I was dumping a test string like this dump('test'); and still got that error. I didn't dump doctrine objects.

Do i set zend.exception_ignore_args to On for dev too or just for prod?

according to this https://www.php.net/manual/en/ini.core.php#ini.zend.exception-ignore-args , the default value is 0. Does frankenphp override it itself for prod?

Aug 09 '25 16:08 frenci8

the fact that I have to restart the container again, is that an issue with me only or with frankenphp?

It is unusual and might be an issue with PHP, the worker script, or FrankenPHP. It is hard to say without being able to step through the code and seeing what it is actually doing when it is frozen.

I am on holidays until next week, so I will work on this when I get back

Aug 09 '25 16:08 frenci8

I increased the memory limit to 2gb and I do not get the memory exhausted error anymore

Could it be that your exception trace is huge, or you’re dumping doctrine objects (those things are massive as doctrine will try to render your entire database depending on how you have things set up)? Maybe try setting zend.exception_ignore_args in your php.ini file? (This is turned on with the production ini file that comes with php. IIRC)

I was dumping a test string like this dump('test'); and still got that error. I didn't dump doctrine objects.

We are talking about your thrown exception. Every exception in php contains a stack trace. If the memory it takes to construct the stack trace is more memory than you have available, you will run out of memory.

Do i set zend.exception_ignore_args to On for dev too or just for prod?

according to this https://www.php.net/manual/en/ini.core.php#ini.zend.exception-ignore-args , the default value is 0. Does frankenphp override it itself for prod?

FrankenPHP doesn't know what you are running. You will need to set this yourself.

Aug 09 '25 16:08 withinboredom