From owner-freebsd-hackers  Thu Feb  8 18:34:22 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP
	id A87CF37B4EC; Thu,  8 Feb 2001 18:34:04 -0800 (PST)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.1/8.9.3) id f192XTi18762;
	Thu, 8 Feb 2001 18:33:29 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 8 Feb 2001 18:33:29 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200102090233.f192XTi18762@earth.backplane.com>
To: Archie Cobbs <archie@dellroad.org>
Cc: freebsd-hackers@FreeBSD.ORG, phk@FreeBSD.ORG
Subject: Re: new /etc/malloc.conf option
References:  <200102082038.MAA56927@curve.dellroad.org>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:Here's an idea for a new /etc/malloc.conf option to help with
:debugging... I'm interested in what other people think.
:
:The option would have the effect of setting a "failure probability"
:P between 0.0 and 1.0 such that any malloc()/realloc() operation would
:fail with probability P.
:...
:
:By using random(), the exact failure can be reproduced by the application
:
:-Archie
:__________________________________________________________________________
:Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

    A system-wide global?  Ouch.  How about not.

    I can't imagine using this on random software.  I can see it for
    big projects, but in that case why not simply write a wrapper
    for malloc() for that project?

    I usually wrap malloc() with a function called zalloc() (which also
    zero's the returned memory), and free() with a function called
    zfree() which takes an extra size argument.  The debug version of
    these functions track and verify all allocations and frees based on
    the source file, line, and function they were called from (cpp magic) and
    dumps a histogram every 10K allocations or so (which makes finding
    memory leaks trivial).

    The default version also core dumps the programs if the underlying
    malloc() fails.  I have safe_*() versions of all the string/malloc
    functions as well (e.g. safe_asprintf(), safe_strdup()) which also core
    the program if the underlying malloc fails.

    I've found that code becomes utterly unreadable if every single call that
    might malloc something has to be checked for failure.  It's easier to
    design the program such that a malloc failure should never occur (for
    example, by limiting the number of simultanious connections a threaded
    program is allowed to handle), and then core dump if one actually does
    occur.

					-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message