When trying to deliver a big mail with procmail as the local delivery agent, procmail can eat all your swap and the machine simply swaps to death (I was able to reproduce this on my machine by sending the netscape binary to myself :). Martijn Koster <mak@webcrawler.com> has mentioned on the -stable mailing list that replacing the malloc.c in libc with the one from -current helps and I tried it and now the machine still swaps like hell but it doesn't halt like it did before, instead procmail is killed with a simple "Out of memory". I'm not sure whether the underlying problem is procmail or the new malloc introduced with 2.2, but I know that procmail was working just fine with 2.1.x and as soon as I upgraded to 2.2.x it started acting up, so I suspect malloc is at fault. Fix: One fix that IMHO should be done is upgrading malloc.c to the one from -current (a close inspection of the changes reveals a typo in the -stable malloc.c which should be fixed anyway). Possibly also procmail is buggy as replacing procmail with mail.local works just fine. How-To-Repeat: Install procmail as local delivery agent for sendmail and send some big mail to yourself (the netscape binary MIME encoded will do just fine).
(Bounced off by joerg@freebsd.org, so PR # 4526 can be closed as being a dup for PR # 4524.) This provides more information for bin/4524 Repeatedly calling realloc causes much more memory to be used then you'd expect. For example, when procmail tried reading an 8M message, this was sufficient to run a 64M (128M swap) machine doing nothing else out of swap (and into the ground :-) This code reproduced the problem outside procmail: #include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char* argv[]) { size_t size = 0; char *p = NULL; int max = 8404992; if (argc > 2) { fprintf(stderr, "Usage: %s maxmem\n", argv[0]); exit(-1); } if (argc > 1) max = atoi(argv[1]); while(1) { size += 16384; if (size > max) break; fprintf(stderr, "realloc(%u)\n", size); if ((p = realloc(p, size)) == NULL) { fprintf(stderr, "out of memory\n"); exit(-1); } } { int c; printf("done. press return to quit\n"); read(0, &c, 1); } } Recompiling the code with the malloc.c from freebsd-current * $Id: malloc.c,v 1.32 1997/08/31 05:59:39 phk Exp $ fixed things (as did recompiling libc with that malloc.c) Now the program is killed after getting much further than before; (I assume when it hits its resource limits) instead of impacting the machine. This fix was previously reported by jfieber@indiana.edu back in June -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
This appears to be the same as in kern/3690. Using the newer malloc.c doesn't work here, but the machine doesn't hang anymore.
State Changed From-To: open->closed There are no signs of bugs in this case. procmail could probably use a smarter algorithm for reading in files.