On Tue, 29 Jan 2002, Mark Morley wrote:
> > The case I saw before was using $message_headers in the filter file. I
> > have fixed this in Exim 4 by restricting the length of $message_headers
> > to 64K.
>
> Ah, ok, that's probably it then. But even with 1,500 Apparently-to: headers,
> the overall size of all the headers combined was still less than 100K, yet
> Exim allocates well over 500 *megs* of RAM. I haven't looked too closely at
> that code yet, but obviously it's allocating far more memory than is needed
> to simply store the headers even multiple times.
Yeah, its string functions don't expect this. It is building a single
string out of the headers. When it hits the size of the current buffer,
it allocates a new one, copies the string, and carries on.
Unfortunately, because of the way its store management works, this
doesn't manage to re-use the space in the previous buffer. (At least, I
assume that's what's happening. There is supposed to be some
optimization in there for extending buffers, but it obviously isn't
working in this case.) Also, it assumes it is dealing with modest length
strings, and doesn't extend the buffer size by very much (50 bytes).
I'll have a look to see if this can be improved one of these days.
> What happenes when it reaches the 64K limit? Will it give up and exit like
> it does when it uses up all available RAM? Or will a queue runner freeze
> the message and carry on with the next one?
It just truncates the data.
I now rather think that $message_headers was a bad idea.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
