Re: [exim] 4.96-RC1 issue

Top Page
Delete this message
Reply to this message
Author: Laura Williamson
Date:  
To: exim-users
Subject: Re: [exim] 4.96-RC1 issue

we are having 100+ rules like these in the central_filter

if $message_body: contains "blah blah"
         logfile /var/log/refuse.log
         logwrite "A1A32 $tod_log $original_domain $message_id
$sender_address"
           fail text "Mail has not been delivered as it is marked as
spam. Check content and resend"
         seen finish
endif

if $message_body: contains "another blah blah check"
         logfile /var/log/refuse.log
         logwrite "A1A33 $tod_log $original_domain $message_id
$sender_address"
           fail text "Mail has not been delivered as it is marked as
spam. Check content and resend"
         seen finish
endif

in the central_filter, removing those delivers the message correctly,
appears that there is an array that is not emptied after each
message_body compare and therefore goobles up memory and fails when
reaching 2gb?


On 23/05/2022 16:42, Jeremy Harris via Exim-users wrote:
> On 23/05/2022 16:04, Laura Williamson via Exim-users wrote:
>> Have another one (in queue, undelivered) that I can test with.
>
> # exim -d+all -M <message-id> 2>&1 | tee my_debug_log_file
>
> should get us debug for an attempt to deliver a message
> that is queued.  With luck that will help locate where
> it's doing this odd memory-allocation.  The important bit
> will be that leading up to the log line being generated
> (I assuming this is the same problem, and not another one!)
>
> There will be quite a lot of debug output, hence the above
> commandline to copy it also to a file.
>
> It's reasonably likely that the "internal problem in central_filter
> router"
> line results from a subprocess dying, and that the "bad memory
> allocation"
> line is in that subprocess (when that is logged, the process doing
> so dies voluntarily).