From blaz@amis.net  Sat Sep 13 06:59:59 1997
Received: from server.amis.net (blaz@server.amis.net [193.77.234.34])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA05013
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 13 Sep 1997 06:59:47 -0700 (PDT)
Received: (from blaz@localhost)
	by server.amis.net (8.8.7/8.8.6/970802) id PAA28431;
	Sat, 13 Sep 1997 15:59:39 +0200 (CEST)
Message-Id: <199709131359.PAA28431@server.amis.net>
Date: Sat, 13 Sep 1997 15:59:39 +0200 (CEST)
From: Blaz Zupan <blaz@amis.net>
Reply-To: blaz@amis.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: Possible buggy malloc in -stable
X-Send-Pr-Version: 3.2

>Number:         4524
>Category:       bin
>Synopsis:       procmail can swap machine to death with malloc.c from -stable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 13 07:00:01 PDT 1997
>Closed-Date:    Thu Sep 18 04:08:24 PDT 1997
>Last-Modified:  Thu Sep 18 04:09:27 PDT 1997
>Originator:     Blaz Zupan
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
Medinet
>Environment:

	procmail 3.11p4 as installed from the ports collection,
	latest 2.2-STABLE

>Description:

	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.

>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).

>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.


>Release-Note:
>Audit-Trail:

From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: Re: bin/4524
Date: Sat, 13 Sep 1997 22:11:28 +0200

 (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. ;-)

From: Andre <Andre.Albsmeier@mchp.siemens.de>
To: freebsd-gnats-submit@freebsd.org, j@uriah.heep.sax.de
Cc:  Subject: Re: bin/4524: procmail can swap machine to death with malloc.c from -stable
Date: Thu, 18 Sep 1997 12:15:29 +0200

 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 
State-Changed-By: phk 
State-Changed-When: Thu Sep 18 04:08:24 PDT 1997 
State-Changed-Why:  

There are no signs of bugs in this case.  procmail could probably use 
a smarter algorithm for reading in files. 
>Unformatted:
