Dear Maintainer,

When transferring large files (obvious with 48 TB, can be seen with 70
GB) with apache2 as server leads to that apache2 thread using memory at
a rate of at least 0.5% of what has been transferred so far. Can be seen
with 'top' sorted on memory size, and in systemctl status apache2 .

This only happens with https, http is fine. Has been confirmed to occur
with trixie and testing (with just apache2 being the testing version)
and a cloud VPS running trixie.

curl is used as a test client, outputting to /dev/null. On ^C, the
memory footprint of the apache2 thread shrinks by around 5 GB per top
refresh and then settles at the normal (low) level.

File transfer via reverse proxy to another server (as in, apache2 only
handles the SSL) does not increase memory footprint of the apache2 thread.

The machine will suffer memory starvation if the file download
continues, i.e, 64GB RAM test machine stalls at around 980 GB transferred.

The only mitigation found is to add a systemd limit in apache2.service,
killing the thread and the file transfer.

Multiple downloads of the same file are served by different apache2
threads and each thread increases in memory footprint.

Many apache2 options and modules have been tested, reducing the
configuration down to the most minimal I could manage while keeping SSL
and the bug still occurs.

This bug is not seen on Debian 10 machines. I've no SSL enabled Debian
11 or 12 machines test machines to hand.

Can you confirm this?

control: tags -1 + moreinformation
control: forwarded -1 https://bz.apache.org/bugzilla/show_bug.cgi?id=70167

Hi

Can you give use more detail on this bug. I have just opened a bug upstream.

control: tags -1 + moreinfo

Le mercredi 5 août 2026, 16:46:55 heure d’été d’Europe centrale Bastien Roucaries a écrit :
Could you restest with
 EnableMMAP Off

That fixes it, there is no memory increase with MMAP off.

Shortly after the original bug report, I ran an strace on the Apache
process and saw occasional 8k mallocs, appeared to be one per transfer
buffer. With no symbol names there was no good information on the call
stack.

Le jeudi 6 août 2026, 18:44:00 heure d’été d’Europe centrale Greg a écrit :

Did you install debug symbols ?

https://wiki.debian.org/HowToGetABacktrace

With symbols automatically installed, the trace is:

#0  0x00007f6c29e3fdc0 in mmap64 () from
target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6c29f4f1a7 in apr_mmap_create (new=new@entry=0x7ffe3e839050,
file=0x7f6c27b3bba8, offset=16197655892,
     size=size@entry=4194304, flag=flag@entry=1, cont=0x7f6c27b39028) at
./mmap/unix/mmap.c:133
#2  0x00007f6c29f73a1b in file_make_mmap (e=0x7f6c27b461a8,
filelength=11236814634, fileoffset=<optimized out>,
     p=<optimized out>) at ./buckets/apr_buckets_file.c:55
#3  file_bucket_read (e=0x7f6c27b461a8, str=0x7ffe3e8390d8,
len=0x7ffe3e8390e0, block=APR_NONBLOCK_READ)
     at ./buckets/apr_buckets_file.c:90
#4  0x00007f6c293a6133 in ssl_io_filter_output (f=0x7f6c28a33858,
bb=0x7f6c27b3bce8)
     at ./modules/ssl/ssl_engine_io.c:1990
#5  0x0000560df4fcac20 in ap_http_header_filter (f=<optimized out>,
b=<optimized out>)
     at ./modules/http/http_filters.c:1573
#6  0x00007f6c295b8b39 in proxy_html_filter (f=0x7f6c27b3b9a0,
bb=<optimized out>)
     at ./modules/filters/mod_proxy_html.c:873
#7  0x00007f6c29377a85 in xml2enc_ffunc (f=0x7f6c27b3b978,
bb=0x7f6c27b3bce8) at ./modules/filters/mod_xml2enc.c:348
#8  0x0000560df4f99de3 in default_handler (r=0x7f6c27b390a0) at
./server/core.c:5019
#9  0x0000560df4fae948 in ap_run_handler (r=r@entry=0x7f6c27b390a0) at
./server/config.c:169
#10 0x0000560df4faef66 in ap_invoke_handler (r=r@entry=0x7f6c27b390a0)
at ./server/config.c:443
#11 0x0000560df4fc8252 in ap_process_async_request (r=0x7f6c27b390a0) at
./modules/http/http_request.c:452
#12 0x0000560df4fc8411 in ap_process_request (r=r@entry=0x7f6c27b390a0)
at ./modules/http/http_request.c:487
#13 0x0000560df4fc4420 in ap_process_http_sync_connection
(c=0x7f6c28a33290) at ./modules/http/http_core.c:208
#14 ap_process_http_connection (c=0x7f6c28a33290) at
./modules/http/http_core.c:249
#15 0x0000560df4fb8b28 in ap_run_process_connection
(c=c@entry=0x7f6c28a33290) at ./server/connection.c:42
#16 0x0000560df4fb9116 in ap_process_connection
(c=c@entry=0x7f6c28a33290, csd=<optimized out>)
     at ./server/connection.c:217
#17 0x00007f6c29bafcb3 in child_main
(child_num_arg=child_num_arg@entry=1, child_bucket=child_bucket@entry=0)
     at ./server/mpm/prefork/prefork.c:667
#18 0x00007f6c29bb0027 in make_child (s=0x7f6c29c9b4a0, slot=1) at
./server/mpm/prefork/prefork.c:773
#19 0x00007f6c29bb0781 in perform_idle_server_maintenance (p=<optimized
out>) at ./server/mpm/prefork/prefork.c:877
#20 prefork_run (_pconf=<optimized out>, plog=<optimized out>,
s=<optimized out>) at ./server/mpm/prefork/prefork.c:1070
#21 0x0000560df4f8e128 in ap_run_mpm (pconf=pconf@entry=0x7f6c2a050028,
plog=0x7f6c29c94028, s=0x7f6c29c9b4a0)
     at ./server/mpm_common.c:95
#22 0x0000560df4f851f3 in main (argc=<optimized out>, argv=<optimized
out>) at ./server/main.c:843

It was mmap not malloc that I had seen when first looking into this.
strace shows it is mmap() allocating 8k every ~8 128k transfers. strace
shows mmap64 is never called, yet gdb only every breaks on mmap64
despite mmap being specified.