On Thu, Nov 15, 2012 at 9:49 AM, Xinliang David Li <davi...@google.com> wrote: > I am sensing some optimization here :) Is it really important to > collect the full stack trace for the allocation context?
Not important if you want to *find* a bug. Deadly important if you want to *analyze* the bug. The free() traces are even more important than malloc() traces. Trace collection could be disable or reduces for performance. http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Flags > You care > about actual site where the allocation happens -- which might usually > be the calls to the malloc like wrappers. The distance from there to > the leaf should not he too far, right? Hm? You mean the code has xalloc() which calls malloc()? No problem, just one extra frame to unwind and store. --kcc > > David > > > On Thu, Nov 15, 2012 at 9:36 AM, Konstantin Serebryany > <konstantin.s.serebry...@gmail.com> wrote: >> On Thu, Nov 15, 2012 at 9:25 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >>> On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek <ja...@redhat.com> wrote: >>>> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote: >>>>> +dvyukov, +glider, +samsonov >>>>> >>>>> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or >>>>> Alexey may submit the patch upstream. >>>>> Please make sure to comment the reason for using a separate typedef. >>>>> >>>>> We need our custom unwinder based on frame pointers to remain the >>>>> default choice on x86[_64] because this is a hotspot >>>>> and replacing it with any library call (especially if that call does >>>>> not use frame pointers but instead uses debug info) will slow down >>>>> the tool significantly. >>>>> The asan docs explicitly say that you need -fno-omit-frame-pointers to >>>>> get reasonable bug reports. >>>> >>>> The backtrace at asan crash time definitely isn't a hotspot, so that IMHO >>>> is >>>> a place which definitely should use a proper and accurrate library >>>> unwinding. >>> >>> Asan collects stack traces on every malloc/free call. >> >> Right. >> A simple exercise: run 400.perlbench or 483.xalancbmk with asan. >> If the stack traces in malloc/free are enabled (which is the default), >> they consume 10-30% of time (don't remember the exact numbers). >> If we replace fp-based unwinder with something else, this will become 80%. >> Most programs we care about (e.g. Chrome or Firefox) behave very >> similar to 483.xalancbmk, i.e. they are very malloc intensive and have >> deep calls stacks. >> >> --kcc >> >>> >>> >>>> Frame pointers aren't emitted by default on either x86_64 or >>>> i?86, system libraries likely won't have them, unless people rebuild >>>> everything with -fsanitize=address -fno-omit-frame-pointer (unlikely to >>>> happen) etc. So relying on frame pointers is definitely very risky. >>> >>> If a user has asan build where he adds -fsanitize=address, it seems >>> trivial to add -fno-omit-frame-pointer as well. >>> >>>> Even >>>> libasan itself is right now built with, even explicit, >>>> -fomit-frame-pointer. >>> >>> That's the right thing. Asan does not unwind itself and performance >>> critical.
