When piping mail through a filter, procmail tries to allocate an excessive amount of memory due to a bug. The amount it tries to allocate depends on where its data section gets loaded in memory. On my system it allocates 2GB+, yielding an OUT OF MEMORY crash. Patch is attached. Reproducible: Always Steps to Reproduce: The bug is 100% reproducible on my system, but it depends where the linker/loader put the data section of the executable. But on systems where it appears: 1. Create a procmail recipe containing a filter (a pipe whose output is not delivered, but recaptured by procmail for further processing.) 2. Run procmail -m recipe 3. Type in a test message, or just press ctrl-D for a blank one 4. Wait for procmail to timeout several times. While it's doing this you can use strace to watch it allocating gobs of memory. 5. Procmail will bounce the message (for commandline invocation, it will just whine) with an out of memory error. Actual Results: Procmail dies. Expected Results: Procmail delivers a message. I have found the bug and am attaching a patch for it. It's one character, so it should be pretty easy to verify as correct. (The variable Stdfilled is used several times very obviously as the length of a buffer, and then for a realloc, &Stdfilled is used as the length of the buffer instead. Remove the & and all is well.) I have submitted this patch to bug@procmail.org and procmail-dev@procmail.org, but so far no response. (I haven't given them very long, but there's no reason this can't get fixed in Gentoo before upstream gets around to it -- they haven't released since 2001, so it will take them a while.)
Created attachment 136693 [details, diff] Patch to fix the bug. The change is only one character, and it should be pretty easy to verify as correct.
(In reply to comment #1) > Created an attachment (id=136693) [edit] > Patch to fix the bug. > > The change is only one character, and it should be pretty easy to verify as > correct. > This is fixed in procmail-3.22-r9.
