This is an archive of the discontinued LLVM Phabricator instance.

[Sanitizers] Enable stack traces on FreeBSD
ClosedPublic

Authored by kutuzov.viktor.84 on Nov 3 2014, 7:26 AM.

Details

Summary

On FreeBSD 10.0 _Unwind_Backtrace() behaves similarly to its Linux implementation when called from within a signal handler.

Diff Detail

Event Timeline

kutuzov.viktor.84 retitled this revision from to [Sanitizers] Enable stack traces on recent versions of FreeBSD.
kutuzov.viktor.84 updated this object.
kutuzov.viktor.84 edited the test plan for this revision. (Show Details)
kutuzov.viktor.84 added reviewers: kcc, samsonov.
kutuzov.viktor.84 added subscribers: Unknown Object (MLST), emaste.
emaste added inline comments.Nov 3 2014, 8:23 AM
lib/sanitizer_common/sanitizer_stacktrace.h
56

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
56

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().

samsonov added inline comments.Nov 3 2014, 11:28 AM
lib/sanitizer_common/sanitizer_stacktrace.h
56

Why did you switch to const bool instead of returns?
Also, I think it would be cleaner to introduce SANITIZER_CAN_SLOW_UNWIND macro next to SANITIZER_CAN_FAST_UNWIND

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.

kutuzov.viktor.84 retitled this revision from [Sanitizers] Enable stack traces on recent versions of FreeBSD to [Sanitizers] Enable stack traces on FreeBSD.

Updated as described above.

samsonov added inline comments.Nov 5 2014, 6:41 PM
lib/asan/asan_posix.cc
50 ↗(On Diff #15754)

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 ↗(On Diff #15754)

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 ↗(On Diff #15754)

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?

samsonov accepted this revision.Nov 6 2014, 11:41 AM
samsonov edited edge metadata.

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.

This revision is now accepted and ready to land.Nov 6 2014, 11:41 AM
glider accepted this revision.Nov 10 2014, 2:37 AM
glider edited edge metadata.

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

Diffusion closed this revision.Nov 10 2014, 7:13 AM
Diffusion updated this revision to Diff 15977.

Closed by commit rL221595 (authored by vkutuzov).