This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR other/55333: libsanitizer StackTrace::FastUnwindStack wrong x32
On Thu, Nov 15, 2012 at 9:49 AM, Xinliang David Li <davidxl@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.serebryany@gmail.com> wrote:
>> On Thu, Nov 15, 2012 at 9:25 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>> On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek <jakub@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.