Bug#1126491: apache2: memory of apache2 thread increases by 200:1 proportional to https large file transfer => forwarded + more information

On 06/08/2026 21:11, Bastien Roucaries wrote:
> Did you install debug symbols ?

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.