Segfault on PHP 8.4.22 on CPU without AVX (Braswell) #22269

Description

The current php:8.4-apache image (PHP 8.4.22) crashes with SIGSEGV immediately on startup on an Intel Celeron N3160 (Braswell, x86-64-v2, no AVX). The crash happens during php_module_startup, before any script is executed, and is reproducible with all configuration disabled (php -n -v).

The sibling variants php:8.4-cli and php:8.4-fpm (same PHP version 8.4.22, rebuilt Jun 5 2026) work fine on the same machine, as does the previous Apache build php:8.4.21-apache. This suggests the issue is specific to the current build of the apache variant.

Downstream impact: the official nextcloud:stable-apache image (built on this base) is currently unusable on affected hardware — it crashes in its entrypoint with Segmentation fault (core dumped). This is how I originally hit the problem.

Reproduction

$ docker run --rm php:8.4-apache php -n -v; echo "Exit: $?"
Exit: 139

No version output is printed; the process dies before producing any output. Same result without -n. --security-opt seccomp=unconfined makes no difference.

Affected image:

• php:8.4-apache, pulled 2026-06-10
• Image digest: sha256:4f0f7e622b2a919e1c1aac259df5c44653e6abd647aafda0b34767c30833e27e
• /usr/local/bin/php sha256: 4b288fc07445f968f5df120ace14739dcaa82d4487ea8ca71a8a14cdfb42d3de
• PHP version (from php_version.h, since php -v crashes): 8.4.22

Working counter-examples (same machine, same day)

So: 8.4.22 itself is fine (cli/fpm builds from Jun 5 run), and the apache variant was fine up to 8.4.21 (May 19 build). Only the current 8.4.22 apache build crashes.

Crash details

Kernel log (dmesg):

traps: php[1077764] general protection fault ip:7fa241d3ef76 sp:7fffbcd78498 error:0 in libc.so.6[b4f76,7fa241cb2000+163000]

gdb backtrace (taken inside the nextcloud:stable-apache container, whose /usr/local/bin/php is byte-identical — sha256 4b288fc0... — to the one in php:8.4-apache):

Program received signal SIGSEGV, Segmentation fault.
0x00007f77773aaf76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x00007f77773aaf76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000055666ac134f5 in zend_register_functions ()
#2  0x000055666ac14032 in ?? ()
#3  0x000055666ac14a50 in zend_register_internal_class_with_flags ()
#4  0x000055666a85990e in ?? ()
#5  0x000055666a85c9ac in ?? ()
#6  0x000055666ac12467 in zend_startup_module_ex ()
#7  0x000055666ac1250c in ?? ()
#8  0x000055666acb4fcb in zend_hash_apply ()
#9  0x000055666ab9d325 in php_module_startup ()
#10 0x000055666a854f32 in ?? ()
#11 0x00007f777731fca8 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00007f777731fd65 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x000055666a8564d1 in _start ()

The crash is in a libc routine called from zend_register_functions during module startup — i.e. one of the very first string/memory operations PHP performs, with zero extensions and zero ini files loaded (-n).

Note: the libc.so.6 file inside the broken image is byte-identical (sha256 fa430b8f298f817a266046af84a77533185ad6fc4406c7d3787b5a0a0c207826) to the one in the working php:8.3-apache image, and other binaries in the broken image (e.g. sha256sum, bash, cat) run fine — so this is not image-layer corruption and not a broken libc file per se. My working theory is that glibc's runtime CPU dispatch (ifunc) selects a code path during PHP's startup that misbehaves on this CPU / with this particular PHP build, but I can't verify that further on this machine.

Environment

• CPU: Intel Celeron N3160 @ 1.60GHz (Braswell) — x86-64-v2 class, has ssse3, sse4_2, popcnt, no AVX/AVX2
• Virtualization: Proxmox VE guest on a QNAP TS-453A; CPU features are passed through (flags above confirmed via /proc/cpuinfo inside the guest)
• Guest OS: Debian GNU/Linux 13 (trixie), x86_64
• Docker: 29.5.3
• Image architecture: amd64 (matches host, no emulation involved)

Limitations of this report

• I only have this one machine, so I cannot confirm whether the image works on AVX-capable CPUs (i.e. whether this is "broken for everyone" or "broken on pre-AVX CPUs"). Given that the identical PHP version runs fine in the cli/fpm builds here, a CPU-dependent build issue seems most likely.
• The gdb trace above lacks symbols (no debug build available); happy to re-run with anything you suggest.

I can provide further diagnostics on request — the crash is 100% reproducible here.

PHP Version

8.4.22

Operating System

No response