What happened?
I can reproducibly trigger a SIGSEGV on startup when using a custom Go extension built with:
frankenphp extension-init
xcaddy build
php_server enabled
The crash happens with a stack based on FrankenPHP v1.12.0.
The same extension/build flow is stable with FrankenPHP v1.11.3.
Environment
- Dockerized Linux environment
- PHP:
8.5.x
- Go:
1.26.x
- xcaddy:
v0.4.5
- Caddy:
v2.11.x
- FrankenPHP module stack:
github.com/dunglas/frankenphp/caddy
github.com/dunglas/mercure/caddy
github.com/dunglas/vulcain/caddy
- custom Go extension module
Reproduction Outline
- Generate extension glue code with:
frankenphp extension-init
- Build FrankenPHP binary with xcaddy and the custom extension module.
- Start FrankenPHP using a Caddyfile that includes
php_server.
Example command:
frankenphp run --config /etc/caddy/Caddyfile --adapter caddyfile
Expected Behavior
FrankenPHP starts and stays running.
Actual Behavior
Process exits with SIGSEGV shortly after startup.
Backtrace (gdb excerpt)
The crash appears in PHP startup internals:
php_module_startup
zend_hash_copy
Example:
Thread received signal SIGSEGV, Segmentation fault.
0x... in zend_hash_copy () from /usr/local/lib/libphp.so
#...
#... in php_module_startup () from /usr/local/lib/libphp.so
Narrowing Results
- Minimal Caddy config without
php_server: no crash.
- Config including
php_server: crash reproduces.
- This suggests the fault is in PHP runtime/module startup interaction, not basic Caddy parsing.
Version Comparison
Crashing setup (v1.12.0 path)
- FrankenPHP base/image around
1.12.0
frankenphp/caddy@v1.12.0
- Caddy around
v2.11.2
Stable setup (v1.11.3 path)
dunglas/frankenphp:1.11.3-php8.5
frankenphp/caddy@v1.11.3
mercure/caddy@v0.21.8
vulcain/caddy@v1.2.1
caddy v2.11.1
go 1.26.0
xcaddy v0.4.5
With the stable set above, the service runs healthy and no SIGSEGV appears.
Build Type
Docker (Debian Trixie)
Worker Mode
Yes
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
PHP 8.5.3
Architecture: aarch64 & x86_64 (issue on both)
Thread Safety: enabled (ZTS)
OPcache: enabled
JIT: disabled
Server API: CLI
Loaded extensions:
apcu, gd, intl, pcntl, pdo_mysql, pdo_pgsql, pgsql, redis, sockets, sodium, zip
Relevant log output
What happened?
I can reproducibly trigger a
SIGSEGVon startup when using a custom Go extension built with:frankenphp extension-initxcaddy buildphp_serverenabledThe crash happens with a stack based on FrankenPHP v1.12.0.
The same extension/build flow is stable with FrankenPHP v1.11.3.
Environment
8.5.x1.26.xv0.4.5v2.11.xgithub.com/dunglas/frankenphp/caddygithub.com/dunglas/mercure/caddygithub.com/dunglas/vulcain/caddyReproduction Outline
frankenphp extension-initphp_server.Example command:
Expected Behavior
FrankenPHP starts and stays running.
Actual Behavior
Process exits with
SIGSEGVshortly after startup.Backtrace (gdb excerpt)
The crash appears in PHP startup internals:
php_module_startupzend_hash_copyExample:
Narrowing Results
php_server: no crash.php_server: crash reproduces.Version Comparison
Crashing setup (v1.12.0 path)
1.12.0frankenphp/caddy@v1.12.0v2.11.2Stable setup (v1.11.3 path)
dunglas/frankenphp:1.11.3-php8.5frankenphp/caddy@v1.11.3mercure/caddy@v0.21.8vulcain/caddy@v1.2.1caddy v2.11.1go 1.26.0xcaddy v0.4.5With the stable set above, the service runs healthy and no
SIGSEGVappears.Build Type
Docker (Debian Trixie)
Worker Mode
Yes
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
PHP 8.5.3 Architecture: aarch64 & x86_64 (issue on both) Thread Safety: enabled (ZTS) OPcache: enabled JIT: disabled Server API: CLI Loaded extensions: apcu, gd, intl, pcntl, pdo_mysql, pdo_pgsql, pgsql, redis, sockets, sodium, zipRelevant log output