There's no issue with the asan allocator, but we use a variety of custom allocators (tcmalloc, jemalloc, some home-rolled stuff), and wouldn't want to disable test coverage those allocators on our buildbots.
On Wed, Jan 31, 2018 at 4:24 PM, Kuba Mracek <[email protected]> wrote: > What's the problem(s) with the ASan allocator that prevent you from doing > that? > > Kuba > > On Jan 31, 2018, at 1:23 PM, Francis Ricci <[email protected]> wrote: > > Thanks for all of the context! Given that it seems possible (pending any > extra info from Kostya), I will probably poke around at this over the next > few months. This would allow us to do things like enabling asan by default > on builds, which would be really awesome to have. > > Francis > > From: <[email protected]> on behalf of Kuba Mracek <[email protected]> > Date: Wednesday, January 31, 2018 at 1:17 PM > To: address-sanitizer <[email protected]>, Dan Liew > <[email protected]>, Francis Ricci <[email protected]>, Kostya Serebryany > <[email protected]> > Subject: Re: Adding "pass-through" ASan allocator > > If you're careful enough (and make sure the allocator itself is not > instrumented, nor does it call *any* intercepted functions, or have some way > of disabling interceptors when we're in the middle of an allocator call), > this should be theoretically possible. > > Dan is right about the quarantine, but it should be possible to build the > quarantine as another layer on top an existing allocator. The quarantine > would just not call the underlaying free() unless the memory is to be > released from the quarantine. Actually, I think the quarantine in ASan is > already decoupled from the allocator and could probably be used against > other allocators. > > Needless to say, doing this would require quite a lot of changes to the > existing allocator(s). > > Kostya, are there some extra features in the sanitizer allocator(s) that a > system/user allocator wouldn't have? > > Kuba > > > On Jan 12, 2018, at 8:49 AM, Dan Liew <[email protected]> wrote: > > Hi, > > On 12 January 2018 at 08:37, Francis Ricci <[email protected]> wrote: > > Hi all, > > I may be missing something conceptually with the way ASan works, but > is there any reason that ASan couldn't pass-through allocations to the > user's allocator? For example: > > 1) User calls malloc() > 2) ASan intercepts malloc(), does checks/adds metadata, etc > 3) Instead of using the sanitizer allocator, ASan calls back into the > user's malloc(). > > Barring technical challenges here with the way interception works, is > there any reason this couldn't work from an allocation perspective? > Would it just be very slow? Or does the sanitizer allocator actually > do a lot of extra work besides just allocating memory? > > > I believe one of the reasons that ASan has a custom allocator is to > detect use-after-free bugs. > When memory is freed, that memory is placed in a quarantine area. By > placing the freed memory > in the quarantine, future calls to `malloc()` can't return the freed > memory (unless the memory gets evicted from the quarantine) and ASan > can record in its shadow > memory that the region of memory that was freed should not be > accessed. Then if the user's code tries to read or write to this freed > memory > ASan can report a use-after-free error. > > If you used your own allocator in ASan it might (and probably would > given that its likely optimized for performance, not bug finding) > return regions of memory that have previously been freed and thus ASan > would miss use-after-free bugs. > > HTH, > Dan. > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
