: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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message