From owner-freebsd-bugs  Sat Sep 13 13:20:09 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA25401
          for bugs-outgoing; Sat, 13 Sep 1997 13:20:09 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA25352;
          Sat, 13 Sep 1997 13:20:01 -0700 (PDT)
Date: Sat, 13 Sep 1997 13:20:01 -0700 (PDT)
Message-Id: <199709132020.NAA25352@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: bin/4524
Reply-To: j@uriah.heep.sax.de (J Wunsch)
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/4524; it has been noted by GNATS.

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