Bug#1125713: apache2: Upgrade to 2.4.66-1~deb12u1 produces zombie PHP processes with FastCGI

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
>>
>