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.
