This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Simple checking allocator
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org, Andi Kleen <andi at firstfloor dot org>
- Date: Mon, 2 Dec 2013 13:58:29 +0100
- Subject: Re: [RFC] Simple checking allocator
- Authentication-results: sourceware.org; auth=none
- References: <20131021193617 dot GA29829 at domone dot podge> <8738nstl06 dot fsf at tassilo dot jf dot intel dot com> <20131023095158 dot GB6795 at domone dot podge> <201312011701 dot 39698 dot vapier at gentoo dot org>
On Sun, Dec 01, 2013 at 05:01:38PM -0500, Mike Frysinger wrote:
> On Wednesday 23 October 2013 05:51:58 OndÅej BÃlka wrote:
> > On Wed, Oct 23, 2013 at 02:05:45AM -0700, Andi Kleen wrote:
> > > OndÅej BÃlka <email@example.com> writes:
> > > > Comments?
> > >
> > > Better to just rely on valgrind or AddressSanitizer? Those
> > > will be always better for this.
> > Could if you accept a slowdown.
> > This one is more ligthweight approach with small slowdown on single thread
> > applications.
> > One of applications is that we could do bound checking of
> > strcat/strcpy also for heap allocated memory.
> ASAN slowdown is getting better and afaik, it's at the point where it's
> perfectly bearable for testing purposes. the Chromium projects builds all of
> Chromium with it and runs tests against it.
Still it is not single percent slowdown so it could not be used in production.
Also not all platforms are supported.
These are arguments to keep mcheck/mtrace, so I asked if that could be
dropped and it still has a userbase.
Then what is left is to write a better alternative where we look for
alternative implementations. I could write a wrapper over allocator but
it will have worse memory consumption.