Date: Wed, 30 Nov 2005 22:51:52 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: freebsd-current@freebsd.org Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Jason Evans <jasone@canonware.com>, current@freebsd.org Subject: Re: New libc malloc patch Message-ID: <200511302252.05741.doconnor@gsoft.com.au> In-Reply-To: <6861.1133349506@critter.freebsd.dk> References: <6861.1133349506@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, 30 Nov 2005 21:48, Poul-Henning Kamp wrote: > In message <20051130111017.GA67032@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. > > 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 :) > For all practical purposes, the options J, A, X & Z are the most commonly > used. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDjZlt5ZPcIHs/zowRAnhxAKCp2p5SYlq0IC2fB4xM+I/lSW0XAQCeIApz HTETzLR6SBVsz4evY6IcZbk= =4c4c -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511302252.05741.doconnor>