Re: New libc malloc patch

From: Ulrich Spoerlein <q_at_galgenberg.net>
Date: Wed, 30 Nov 2005 13:30:19 +0100
Daniel O'Connor wrote:
> On Wed, 30 Nov 2005 21:48, Poul-Henning Kamp wrote:
> > In message <20051130111017.GA67032_at_galgenberg.net>, Ulrich Spoerlein writes:
> > >I just read that mmap() part and have to wonder: Is it possible to
> > >introduce something like the guard pages that OpenBSD has implemented?
> > >I'd love to try this out and see the dozens of applications that fail
> > >due to off-by-one bugs.
> >
> > Guard-pages are very expensive and that is why I have not adopted
> > OpenBSD's patch.

Yes, of course it should be disabled as default, but if it could be
implemented so you can switch at runtime or compile time (think
INVARIANTS/WITNESS) *and* there is no penalty for the disabled case,
that be nice.

> > I would advocate that people use one of the dedicated debugging malloc
> > implementations (ElectricFence ?) instead of putting too much overhead
> > into our default malloc.
> 
> Electric fence is right. Although it IS slow, an order of magnitude or more 
> usually. Also if you do use it you'll probably have to bump up the 
> vm.max_proc_mmap sysctl or it will fail to allocate memory.
> 
> Another good one is valgrind (and it detects more problems to boot :)

Yes, I usualy use dmalloc and valgrind. It's sad other developers don't
use any of these tools ...

Ulrich Spoerlein
-- 
 PGP Key ID: F0DB9F44				Encrypted mail welcome!
Fingerprint: F1CE D062 0CA9 ADE3 349B  2FE8 980A C6B5 F0DB 9F44
Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
didn't you understand?

Received on Wed Nov 30 2005 - 11:30:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC