1) I agree it's not wise to call _UnwindBacktrace if we're interested only in the top frame. We can probably handle the case for getting stack traces of sizes 0 and 1 in StackTrace::Unwind() in a generic way to avoid doing any extra job. 2) Currently the top frame in the allocation stack is a function in ASan runtime, so I assume you mean malloc_context_size=2. I don't like the idea of introducing a special case for malloc_context_size=1 in our malloc/new interceptors, and the code in asan/asan_stack.h is way too hairy already. I also think that the top frame in allocation/free stack should be from ASan runtime, not in the user code. However, that's just my opinion. Do you have any stats/justifications for that proposal? E.g. is ASan unwinder visible in profile for malloc-intensive application even for small values of malloc_context_size?
On Tue, Mar 4, 2014 at 11:54 AM, Yuri Gribov <[email protected]> wrote: > Hi all, > > I wonder if it would make sense to speed up the current malloc context > code for malloc_context_size=1 case. This case is often enough to > locate error and can be implemented with zero overhead (by passing > __builtin_return_address() from malloc/new interceptors to ASan > unwinder). > > -Y > > -- > 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/groups/opt_out. > -- Alexey Samsonov, MSK -- 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/groups/opt_out.
