[php-src] Issue #22269: Segfault on PHP 8.4.22 on CPU without AVX (Braswell)

Issue: https://github.com/php/php-src/issues/22269
Author: masty76

### Description

<p>The current <code>php:8.4-apache</code> image (PHP 8.4.22) crashes with SIGSEGV immediately on startup on an Intel Celeron N3160 (Braswell, x86-64-v2, <strong>no AVX</strong>). The crash happens during <code>php_module_startup</code>, before any script is executed, and is reproducible with all configuration disabled (<code>php -n -v</code>).</p>
<p>The sibling variants <code>php:8.4-cli</code> and <code>php:8.4-fpm</code> (same PHP version 8.4.22, rebuilt Jun 5 2026) work fine on the same machine, as does the previous Apache build <code>php:8.4.21-apache</code>. This suggests the issue is specific to the current build of the apache variant.</p>
<p>Downstream impact: the official <code>nextcloud:stable-apache</code> image (built on this base) is currently unusable on affected hardware — it crashes in its entrypoint with <code>Segmentation fault (core dumped)</code>. This is how I originally hit the problem.</p>
<h2>Reproduction</h2>
<pre><code class="language-console">$ docker run --rm php:8.4-apache php -n -v; echo "Exit: $?"
Exit: 139
</code></pre>
<p>No version output is printed; the process dies before producing any output. Same result without <code>-n</code>. <code>--security-opt seccomp=unconfined</code> makes no difference.</p>
<p>Affected image:</p>
<ul>
<li><code>php:8.4-apache</code>, pulled 2026-06-10</li>
<li>Image digest: <code>sha256:4f0f7e622b2a919e1c1aac259df5c44653e6abd647aafda0b34767c30833e27e</code></li>
<li><code>/usr/local/bin/php</code> sha256: <code>4b288fc07445f968f5df120ace14739dcaa82d4487ea8ca71a8a14cdfb42d3de</code></li>
<li>PHP version (from <code>php_version.h</code>, since <code>php -v</code> crashes): 8.4.22</li>
</ul>
<h2>Working counter-examples (same machine, same day)</h2>

Image | PHP version / build date | Result
-- | -- | --
php:8.4-cli | 8.4.22, built Jun 5 2026 22:40:17 | ✅ works
php:8.4-fpm | 8.4.22, built Jun 5 2026 22:41:01 | ✅ works
php:8.3-cli | 8.3.31, built May 19 2026 23:11:46 | ✅ works
php:8.3-apache | 8.3.31, built May 19 2026 23:11:54 | ✅ works
nextcloud:33.0.4-apache (contains PHP 8.4.21-apache) | 8.4.21, built May 19 2026 23:10:04 | ✅ works
php:8.4-apache | 8.4.22 (current) | ❌ SIGSEGV on startup
nextcloud:stable-apache (contains identical PHP binary, sha256 4b288fc0...) | 8.4.22 | ❌ SIGSEGV on startup
debian:trixie (base distro sanity check) | — | ✅ works


<p>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.</p>
<h2>Crash details</h2>
<p>Kernel log (<code>dmesg</code>):</p>
<pre><code>traps: php[1077764] general protection fault ip:7fa241d3ef76 sp:7fffbcd78498 error:0 in libc.so.6[b4f76,7fa241cb2000+163000]
</code></pre>
<p>gdb backtrace (taken inside the <code>nextcloud:stable-apache</code> container, whose <code>/usr/local/bin/php</code> is byte-identical — sha256 <code>4b288fc0...</code> — to the one in <code>php:8.4-apache</code>):</p>
<pre><code>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 ()
</code></pre>
<p>The crash is in a libc routine called from <code>zend_register_functions</code> during module startup — i.e. one of the very first string/memory operations PHP performs, with zero extensions and zero ini files loaded (<code>-n</code>).</p>
<p>Note: the <code>libc.so.6</code> file inside the broken image is byte-identical (sha256 <code>fa430b8f298f817a266046af84a77533185ad6fc4406c7d3787b5a0a0c207826</code>) to the one in the working <code>php:8.3-apache</code> image, and other binaries in the broken image (e.g. <code>sha256sum</code>, <code>bash</code>, <code>cat</code>) 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.</p>
<h2>Environment</h2>
<ul>
<li><strong>CPU:</strong> Intel Celeron N3160 @ 1.60GHz (Braswell) — x86-64-v2 class, has <code>ssse3</code>, <code>sse4_2</code>, <code>popcnt</code>, <strong>no AVX/AVX2</strong></li>
<li><strong>Virtualization:</strong> Proxmox VE guest on a QNAP TS-453A; CPU features are passed through (flags above confirmed via <code>/proc/cpuinfo</code> inside the guest)</li>
<li><strong>Guest OS:</strong> Debian GNU/Linux 13 (trixie), x86_64</li>
<li><strong>Docker:</strong> 29.5.3</li>
<li><strong>Image architecture:</strong> amd64 (matches host, no emulation involved)</li>
</ul>
<h2>Limitations of this report</h2>
<ul>
<li>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.</li>
<li>The gdb trace above lacks symbols (no debug build available); happy to re-run with anything you suggest.</li>
</ul>
<p>I can provide further diagnostics on request — the crash is 100% reproducible here.</p></body></html>

### PHP Version

```plain
8.4.22
```

### Operating System

_No response_