From owner-freebsd-hackers Thu Feb 8 13: 1: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 7526E37B6D5 for ; Thu, 8 Feb 2001 13:00:41 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f18L0Lw18306; Thu, 8 Feb 2001 22:00:21 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Archie Cobbs Cc: freebsd-hackers@freebsd.org Subject: Re: new /etc/malloc.conf option In-Reply-To: Your message of "Thu, 08 Feb 2001 12:38:38 PST." <200102082038.MAA56927@curve.dellroad.org> Date: Thu, 08 Feb 2001 22:00:21 +0100 Message-ID: <18304.981666021@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102082038.MAA56927@curve.dellroad.org>, Archie Cobbs writes: >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. It's a good idea, but it needs improvement. If malloc() fails with a finite probability you will never get to test the end-game for most processes. Ideally you would give malloc a flag to say 'L'ook for failure, and some covert channel would be dug through which you can control the probability in batch or realtime mode. Either way, I'm not sure it belongs in phkmalloc() -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message