https://bugs.exim.org/show_bug.cgi?id=3047
--- Comment #23 from Simon Arlott <[email protected]> --- I can now reproduce it. The difference between pcre2 v10.34 and v10.42 is that the later version is also making allocations of 20480 bytes and that's causing Exim to increase pp->store_block_order to 31 resulting in a 2GB allocation: 14:56:51 303075 check_dir_size: size from 18933.M685199P49010.server1.tld,S=94030,W=9068:2,S is 94030 function_store_get: 128 function_store_get: 20480 Thread 3.1 "exim" hit Breakpoint 1, internal_store_malloc (size=2147483632, func=0x555555629ab0 <__FUNCTION__.20006> "function_store_get", line=70) at store.c:1156 1156 log_write(0, LOG_MAIN|LOG_PANIC_DIE, (gdb) bt #0 internal_store_malloc (size=2147483632, func=0x555555629ab0 <__FUNCTION__.20006> "function_store_get", line=70) at store.c:1156 #1 0x00005555555f5d19 in pool_get (pp=0x5555556c0160 <paired_pools>, size=20480, align_mem=0, func=0x555555629ab0 <__FUNCTION__.20006> "function_store_get", linenumber=70) at store.c:449 #2 0x00005555555f6528 in store_get_3 (size=size@entry=20480, proto_mem=proto_mem@entry=0x0, func=func@entry=0x555555629ab0 <__FUNCTION__.20006> "function_store_get", linenumber=linenumber@entry=70) at store.c:519 #3 0x0000555555598acb in function_store_get (size=20480, tag=<optimised out>) at exim.c:70 #4 0x00007ffff7c09fc5 in pcre2_match_8 (code=code@entry=0x5555556d1a28, subject=subject@entry=0x5555556fd19b "11765.M685199P49010.server1.tld,S=258620,W=1215:2,S", length=51, length@entry=18446744073709551615, start_offset=start_offset@entry=0, options=options@entry=0, match_data=match_data@entry=0x7fffb79a1328, mcontext=<optimised out>) at src/pcre2_match.c:6848 #5 0x000055555560b9de in check_dir_size (dirname=dirname@entry=0x5555556e89b0 "/dev/shm/exim/Maildir/cur", countptr=countptr@entry=0x7ffffffbcec4, re=re@entry=0x5555556d1a28) at appendfile.c:684 #6 0x000055555560ba7c in check_dir_size (dirname=dirname@entry=0x5555556ce158 "/dev/shm/exim/Maildir", countptr=countptr@entry=0x7ffffffbd050, re=re@entry=0x5555556d1a28) at appendfile.c:721 #7 0x000055555560ddc0 in appendfile_transport_entry (tblock=0x5555556d1528, addr=0x5555556e34c8) at appendfile.c:2388 #8 0x000055555558f756 in deliver_local (addr=addr@entry=0x5555556e34c8, shadowing=shadowing@entry=0) at deliver.c:2387 #9 0x00005555555909ad in do_local_deliveries () at deliver.c:3004 #10 0x0000555555593e14 in deliver_message (id=<optimised out>, forced=forced@entry=0, give_up=give_up@entry=0) at deliver.c:8003 #11 0x00005555555a23b0 in main (argc=5, cargv=0x7fffffffd9b8) at exim.c:6071 (gdb) down #1 0x00005555555f5d19 in pool_get (pp=0x5555556c0160 <paired_pools>, size=20480, align_mem=0, func=0x555555629ab0 <__FUNCTION__.20006> "function_store_get", linenumber=70) at store.c:449 449 newblock = internal_store_malloc(mlength, func, linenumber); (gdb) p mlength $1 = 2147483632 (gdb) p size $2 = 20480 (gdb) p length $3 = 2147483616 (gdb) p pp->store_block_order $4 = 31 (gdb) p *pp $5 = {chainbase = 0x5555556c36e8, current_block = 0x7fff779a2018, next_yield = 0x7fffb79a13a8, yield_length = 3168, store_block_order = 31, store_last_get = 0x7fffb79a1328, nbytes = 36640, maxbytes = 1073778496, nblocks = 20, maxblocks = 20, maxorder = 31} My config just uses an "accept" router to invoke the local_virtual_delivery transport. It looks like none of the memory ever gets free'd. After enough allocations of 128+20480 bytes (104207+ files) it exits. This works ok on v10.34 because that only allocates 112 bytes per file. -- You are receiving this mail because: You are on the CC list for the bug. -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/ ## unsubscribe (doesn't require an account): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
