This is the mail archive of the
libc-alpha@sourceware.org
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 <neleai@seznam.cz> 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.
> -mike
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.