Salut Bastien,
oh, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125368 somehow
evaded me, I'm sorry.
Otherwise I would have referenced the older bug report (and my debugging
work would have been cut short ...)
> Could you test apache2 experimental ?
The packages from experminatal seem to fix the issue, I could not
reproduce the segfaults with them (just like with my own patched
Bookworm/Trixie packages).
Thanks for your work on the package,
Cheers,
Thomas
Am 21.01.26 um 12:12 schrieb Bastien Roucaries:
Le mercredi 21 janvier 2026, 11:49:35 heure normale d’Europe centrale Thomas
Stangner a écrit :
Hi,
I also ran into this problem and was able to generate coredumps to debug
the issue.
The zombie FCGI processes are caused by segfaulting parent Apache2
processes:
[Wed Jan 21 08:15:04.609766 2026] [core:notice] [pid 4996:tid 4996]
AH00052: child pid 36382 exit signal Segmentation fault (11)
[Wed Jan 21 08:40:04.282658 2026] [core:notice] [pid 4996:tid 4996]
AH00052: child pid 85420 exit signal Segmentation fault (11)
[Wed Jan 21 08:54:05.207724 2026] [core:notice] [pid 4996:tid 4996]
AH00052: child pid 22762 exit signal Segmentation fault (11)
The father Apache2 process gets terminated by the segfault and the
previously spawned FCGI child processes end up as zombies, because
nobody does a wait()/waitpid() on them.
The segfaults are caused by a bug in mod_http2:
---------8<--------8<----------
Program terminated with signal SIGSEGV, Segmentation fault.
#0 c1_purge_streams (m=0x7fd5f77fb738) at ./modules/http2/h2_mplx.c:606
[Current thread is 1 (Thread 0x7fd5e27fc6c0 (LWP 79820))]
(gdb) bt full
#0 c1_purge_streams (m=0x7fd5f77fb738) at ./modules/http2/h2_mplx.c:606
stream = 0x7fd5ff5bc0a0
i = 1
#1 0x00007fd602eb1fe0 in h2_mplx_c1_poll (m=0x7fd5f77fb738,
timeout=timeout@entry=0,
on_stream_input=on_stream_input@entry=0x7fd602eb7230 <on_stream_input>,
on_stream_output=on_stream_output@entry=0x7fd602eb70f0
<on_stream_output>, on_ctx=on_ctx@entry=0x7fd5f77fb0a0) at
./modules/http2/h2_mplx.c:659
rv = <optimized out>
#2 0x00007fd602ebb1bc in h2_session_process (session=0x7fd5f77fb0a0,
async=0, pkeepalive=pkeepalive@entry=0x7fd5e27fbd14) at
./modules/http2/h2_session.c:2013
status = 0
c = 0x7fd5f78042c8
rv = <optimized out>
mpm_state = 1
trace = 0
#3 0x00007fd602ea481c in h2_c1_run (c=0x7fd5f78042c8) at
./modules/http2/h2_c1.c:132
status = <optimized out>
mpm_state = 0
keepalive = 0
conn_ctx = 0x7fd5f783a3b0
#4 0x00005623928a4030 in ap_run_process_connection
(c=c@entry=0x7fd5f78042c8) at ./server/connection.c:42
pHook = <optimized out>
n = 4
rv = -1
---------8<--------8<----------
An update to mod_http 2.0.37 resolves the problem (via this upstream patch):
https://github.com/apache/httpd/commit/e41e84e08e6186460e77a8357b5d5c571d33bd76
So I suggest cherry-picking this commit from the 2.4.x branch and
patching/updating mod_http2 from 2.0.35 to 2.0.37.
Could you test apache2 experimental ?
Cheers,
Thomas
