On FreeBSD 10.0 _Unwind_Backtrace() behaves similarly to its Linux implementation when called from within a signal handler.
Details
Diff Detail
Event Timeline
lib/sanitizer_common/sanitizer_stacktrace.h | ||
---|---|---|
68 | Did you check that 9.3 works? (I'm curious if the test should actually be for FreeBSD version < 10.0 .) |
lib/sanitizer_common/sanitizer_stacktrace.h | ||
---|---|---|
68 | I didn't check it on 9.3 and I'm not sure if there is a simple way to find the revision affected the behavior of _Unwind_Backtrace(). |
lib/sanitizer_common/sanitizer_stacktrace.h | ||
---|---|---|
68 | Why did you switch to const bool instead of returns? |
On FreeBSD 10.0 _Unwind_Backtrace() behaves similarly to its Linux implementation when called from within a signal handler.
Wrong. It still return the handler's stack on SIGSEGV. Sorry for misleading. I'm going to prepare another patch that introduce SANITIZER_CAN_SLOW_UNWIND, enable stack traces on FreeBSD and rely on fast unwinding when called from within the Asan's SIGSEGV handler.
lib/asan/asan_posix.cc | ||
---|---|---|
50 | I'd prefer to have RAII object that sets/unsets it. Also, won't we have a data race when one thread checks if it wants to use a fast unwind (e.g. to save an alllocation stack), and another thread hits a segfault and invokes a signal handler? | |
lib/sanitizer_common/sanitizer_internal_defs.h | ||
214 | Please put this in sanitizer_common.h. Also, there are other options apart from SEGV, in_deadly_signal_handler would be a more proper name. | |
lib/sanitizer_common/sanitizer_stacktrace.cc | ||
20 | sanitizer_common.cc | |
lib/sanitizer_common/sanitizer_stacktrace.h | ||
18 | Do you still need this? |
Also, won't we have a data race when one thread checks if it wants to use a fast unwind (e.g. to save an alllocation stack), and another thread hits a segfault and invokes a signal handler?
Sure we will. Thanks for the catch.
Since THREADLOCAL is not supported on OSX and Android and thread-associated data is sanitizer-specific, what if we keep this in Asan and move the code that determines whether we are in a deadly signal handler on FreeBSD from WillUseFastUnwind() (sanitizer_common) to GetStackTraceWithPcBpAndContext() (asan_stack), like in this new patch?
glider, isn't THREADLOCAL supported on all the version of Mac OS X we care about? Not sure about Android, though.
That said, I'm ok with the current version of the patch.
THREADLOCAL is indeed supported on OSX (we haven't switched to using it yet, though). IIRC TLS support isn't finished on Android yet.
The change looks good to me.
lib/sanitizer_common/sanitizer_stacktrace.h | ||
---|---|---|
36 | We'll need to revisit this when slow unwind works on Mac. Please add a comment linking to https://code.google.com/p/address-sanitizer/issues/detail?id=137 |
I'd prefer to have RAII object that sets/unsets it. Also, won't we have a data race when one thread checks if it wants to use a fast unwind (e.g. to save an alllocation stack), and another thread hits a segfault and invokes a signal handler?