Date: Thu, 8 Feb 2001 18:33:29 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Archie Cobbs <archie@dellroad.org> Cc: freebsd-hackers@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: new /etc/malloc.conf option Message-ID: <200102090233.f192XTi18762@earth.backplane.com> References: <200102082038.MAA56927@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102090233.f192XTi18762>