[PATCH] Fix sanitizers' FastUnwindStack() to work in the unwinding state

[Viktor Kutuzov]

> Wait, comment in GetStackTraceWithPcBpAndContext explicitly says that we're "trying to do slow unwind anyways", and here you're running a fast unwind.

Yes, I didn't notice the 't == 0' condition. Thanks.

> What is the case when you need to get a stack trace while you're already unwinding?

In my specific case with null_deref.cc failure on FreeBSD GetCurrentThread() return 0 when called from within a signal handler (ReportSIGSEGV, namely). This is why it falls to the slow unwinding branch.

I'm not sure what this line:
  } else if (t == 0 && !fast) {
is supposed to do. Is the 'fast' parameter a hint/recommendation or a requirement? Note is that the 'fast' parameter is set to whatever 'common_flags()->fast_unwind_on_fatal' is, which is false by default--even on platforms where fast unwinding is the only option (Mac, FreeBSD). On the other hand, the condition above means no stack trace will be provided if 'fast' is raised.

So, it seems like we should either raise 'fast_unwind_on_fatal' (and keep it so) on platforms like Mac and FreeBSD or remove the '!fast' part of the condition.

> If you absolutely need this change, I'd prefer to either fire a call to WillUseFastUnwind() in GetStackTraceWithPcBpAndContext(), or provide better fake values for stack_top/stack_bottom in the call to StackTrace::Unwind().

Since FastUnwindStack() takes the bound values into account, I believe we have to choose some realistic numbers anyway?

http://reviews.llvm.org/D4460