Re: new /etc/malloc.conf option
: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
Re: new /etc/malloc.conf option
In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new /etc/malloc.conf option
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.
Sometimes I've implemented this kind of thing manually to test code
robustness and it's been very helpful in catching obscure bugs.
You can't do this with a single letter, but maybe we could do something
like this using a number between 0..100:
$ ln -s F5AJ /etc/malloc.conf
Then in the malloc code read out the 'F5' at startup and set
failure_prob to 5%...
static u_int failure_prob; /* a number between 0 and 100 */
void *
malloc(size_t len)
{
u_int failure_index;
if (failure_prob != 0 && (random() % 100) < failure_prob) {
errno = ENOMEM;
return (NULL)
}
}
This would then give you a 1% failure probability.
By using random(), the exact failure can be reproduced by the application
by setting the same seed with srandom(). We might want to use a more
precise range, e.g., 0..100 instead of 0..100.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
