zend.max_allowed_stack_size auto-detects ~82KB under ZTS, 500ing ordinary Twig pages #25

New issue

Closed

opened 2026-08-04 11:25:11 +00:00 by geusebio · 0 comments

geusebio commented

2026-08-04 11:25:11 +00:00

Owner

Ordinary Twig-heavy pages return HTTP 500 on this image:

Compile Error: Maximum call stack size of 83936 bytes
(zend.max_allowed_stack_size - zend.reserved_stack_size) reached during compilation.
Try splitting expression

Both settings are at their defaults, i.e. auto-detect:

$ docker run --rm --entrypoint sh matthewbaggett/frankenphp:8.5 -c 'php -i | grep -iE "zend.max_allowed_stack_size|zend.reserved_stack_size|Thread Safety"'
Thread Safety => enabled
zend.max_allowed_stack_size => 0 => 0
zend.reserved_stack_size => 0 => 0

Under ZTS the auto-detection measures FrankenPHP's worker thread stack, which comes out at
~82 KB — far less than a normal ulimit -s 8 MB main stack, so template compilation that
is perfectly fine under php-fpm blows the limit. This is not deep application recursion;
it is a first-page-load failure on a stock Symfony/Twig app.

Workaround, and why it is not a fix

zend.max_allowed_stack_size = -1

clears it (verified — the failing page goes 500 → 302), but -1 disables the guard
entirely: a genuine runaway recursion then segfaults the worker instead of raising a
catchable error. That trade seems wrong to bake into every downstream image.

Suggested fix

Size FrankenPHP's thread stacks so the auto-detected value is sane, or ship an explicit
zend.max_allowed_stack_size that matches the real stack. Either way it belongs here
rather than in each application image.

Ordinary Twig-heavy pages return **HTTP 500** on this image: ``` Compile Error: Maximum call stack size of 83936 bytes (zend.max_allowed_stack_size - zend.reserved_stack_size) reached during compilation. Try splitting expression ``` Both settings are at their defaults, i.e. auto-detect: ``` $ docker run --rm --entrypoint sh matthewbaggett/frankenphp:8.5 -c 'php -i | grep -iE "zend.max_allowed_stack_size|zend.reserved_stack_size|Thread Safety"' Thread Safety => enabled zend.max_allowed_stack_size => 0 => 0 zend.reserved_stack_size => 0 => 0 ``` Under ZTS the auto-detection measures FrankenPHP's worker thread stack, which comes out at ~82 KB — far less than a normal `ulimit -s` 8 MB main stack, so template compilation that is perfectly fine under php-fpm blows the limit. This is not deep application recursion; it is a first-page-load failure on a stock Symfony/Twig app. ### Workaround, and why it is not a fix ```ini zend.max_allowed_stack_size = -1 ``` clears it (verified — the failing page goes 500 → 302), but `-1` disables the guard entirely: a genuine runaway recursion then segfaults the worker instead of raising a catchable error. That trade seems wrong to bake into every downstream image. ### Suggested fix Size FrankenPHP's thread stacks so the auto-detected value is sane, or ship an explicit `zend.max_allowed_stack_size` that matches the real stack. Either way it belongs here rather than in each application image.

geusebio referenced this issue from a commit

2026-08-04 12:25:25 +00:00

frankenphp: give PHP threads a stack it can compile Twig on

geusebio referenced this issue from a pull request that will close it,

2026-08-04 12:26:11 +00:00

frankenphp: give PHP threads a stack it can compile Twig on #30

geusebio closed this issue

2026-08-04 12:49:09 +00:00