https://bugs.exim.org/show_bug.cgi?id=3047
--- Comment #23 from Simon Arlott <bugzilla.exim.simon@???> ---
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):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
