[compiler-rt] r221520 - [sanitizer] Never remove the last frame off the stack trace.

[David Blaikie]

On Fri, Nov 14, 2014 at 7:14 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com
> wrote:

> I've added a comment in r222000.
> Thanks for bringing this up!
>

Sure thing.

Looking at the comment - if the issue is that unwinders might give us
something other than the obvious answer, could/should we narrow this fix a
bit: instead of special casing a 1-frame stack, should we look to see if
the end of the stack is the function we intend to skip (the sanitizers
handler, I take it?) and only swallow that frame if it is? That way if we
get other weird stacks we'll do the right thing and not consume them even
if they have more than one frame.


>
> On Wed, Nov 12, 2014 at 9:48 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> > On Wed, Nov 12, 2014 at 1:03 AM, Evgeniy Stepanov
> > <eugeni.stepanov at gmail.com> wrote:
> >>
> >> We remove frames that belong to the sanitizer runtime off the top of
> >> the stack trace.
> >>
> >> This situation, when the unwinder returned a single-frame stack trace,
> >> was observed in an unusual environment where the CFI unwinder
> >> misbehaved for a yet unknown reason.
> >
> >
> > It'd be nice to have an explanation here at some point, otherwise I'd be
> > concerned about someone removing this code as meaningless.
> >
> >>
> >> It involved building ASan runtime
> >> with a custom build system (neither make or cmake), and I can't
> >> reproduce the results in a test.
> >>
> >> On Wed, Nov 12, 2014 at 1:46 AM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >> >
> >> >
> >> > On Fri, Nov 7, 2014 at 4:03 AM, Evgeniy Stepanov
> >> > <eugeni.stepanov at gmail.com>
> >> > wrote:
> >> >>
> >> >> Author: eugenis
> >> >> Date: Fri Nov  7 06:03:07 2014
> >> >> New Revision: 221520
> >> >>
> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=221520&view=rev
> >> >> Log:
> >> >> [sanitizer] Never remove the last frame off the stack trace.
> >> >
> >> >
> >> > Test case? I'm also not quite sure what this is doing - why are we
> >> > popping/ignoring frames exactly?
> >> >
> >> >>
> >> >>
> >> >> It can only make it worse.
> >> >>
> >> >> Modified:
> >> >>
> >> >>
> >> >>
> compiler-rt/trunk/lib/sanitizer_common/sanitizer_unwind_posix_libcdep.cc
> >> >>
> >> >> Modified:
> >> >>
> >> >>
> compiler-rt/trunk/lib/sanitizer_common/sanitizer_unwind_posix_libcdep.cc
> >> >> URL:
> >> >>
> >> >>
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_unwind_posix_libcdep.cc?rev=221520&r1=221519&r2=221520&view=diff
> >> >>
> >> >>
> >> >>
> ==============================================================================
> >> >> ---
> >> >>
> >> >>
> compiler-rt/trunk/lib/sanitizer_common/sanitizer_unwind_posix_libcdep.cc
> >> >> (original)
> >> >> +++
> >> >>
> >> >>
> compiler-rt/trunk/lib/sanitizer_common/sanitizer_unwind_posix_libcdep.cc Fri
> >> >> Nov  7 06:03:07 2014
> >> >> @@ -116,7 +116,7 @@ void BufferedStackTrace::SlowUnwindStack
> >> >>    // We need to pop a few frames so that pc is on top.
> >> >>    uptr to_pop = LocatePcInTrace(pc);
> >> >>    // trace_buffer[0] belongs to the current function so we always
> pop
> >> >> it.
> >> >> -  if (to_pop == 0)
> >> >> +  if (to_pop == 0 && size > 1)
> >> >>      to_pop = 1;
> >> >>    PopStackFrames(to_pop);
> >> >>    trace_buffer[0] = pc;
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> llvm-commits mailing list
> >> >> llvm-commits at cs.uiuc.edu
> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141114/2ee13ff0/attachment.html>