This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Simple checking allocator

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 <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]