Page MenuHomePhabricator

[sanitizer] Expose __sanitizer_print_stack_trace().
ClosedPublic

Authored by earthdok on Nov 19 2013, 8:31 AM.

Details

Reviewers
samsonov
Summary

Useful for debugging code built with sanitizer tools.

Diff Detail

Event Timeline

samsonov added inline comments.Nov 20 2013, 12:46 AM
include/sanitizer/common_interface_defs.h
88

Specify that this is useful for debugging purposes only.

lib/sanitizer_common/sanitizer_common_libcdep.cc
41 ↗(On Diff #5659)

Looks like this should go to sanitizer_stacktrace_libcdep.cc

45 ↗(On Diff #5659)

What if slow unwind is unavailable (caller can learn about this via StackTrace::WillUseFastUnwind function)?
Also, unwinding a stack from the sanitizer runtime and is (unfortunately) tool-specific. See complicated GET_STACK_TRACE_WITH_PC_AND_BP in ASan runtime and GetStackTrace in MSan runtime. It would be cool to
generalize it somehow, but we're not there at the moment. But we should probably address this before adding a generic
interface usable with all sanitizers - just imagine that you call __sanitizer_print_stack_trace() in your program or in gdb,
and suddenly see an MSan report caused by unblocked interceptors called during _Unwind_Backtrace.

You'll also need lit tests.

earthdok updated this revision to Unknown Object (????).Nov 28 2013, 8:18 AM

implement __sanitizer_get_stack_trace() separately in asan/msan/lsan/tsan

samsonov added inline comments.Nov 29 2013, 12:29 AM
include/sanitizer/common_interface_defs.h
89

What about ubsan or dfsan implementations? If we decide to make this function tool-specific and implement it in a different way in each tool [1], let's start from the tools that need it right now (IIRC you want it for LSan/ASan).

[1] - though, I don't like it. I've spent some time to make stack unwinding and printing more generic (but apparently it's still not generic enough), and I think it would be better to fix the code in such a way that we'll be able to write a single __sanitizer_print_stack_trace in sanitizer_common that would work for all tools.

lib/msan/msan.cc
195 ↗(On Diff #5814)

How does it confuse the unwinder?

lib/tsan/rtl/tsan_interface.cc
90 ↗(On Diff #5814)

interface attribute?

earthdok added inline comments.Nov 29 2013, 3:33 AM
lib/msan/msan.cc
195 ↗(On Diff #5814)

Like this:

#0 0x7fef07e475a8 in __sanitizer_print_stack_trace llvm/projects/compiler-rt/lib/msan/msan.cc:578
#1 0x7fef07e47658 in GetStackTrace san/llvm/projects/compiler-rt/lib/msan/msan.cc:188
#2 0x7fef07e47658 in __sanitizer_print_stack_trace llvm/projects/compiler-rt/lib/msan/msan.cc:579
#3 0x7fef07e8b2e1 in main (reproducers/a.out+0x602e1)
#4 0x7fef06a2c76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
#5 0x7fef07e8b1d4 in _start (reproducers/a.out+0x601d4)

The patch doesn't seem to work for me if I add __sanitizer_print_stack_trace() into BlockingMutex::{Lock,Unlock} in sanitizer_common/sanitizer_linux.cc

earthdok updated this revision to Unknown Object (????).Dec 2 2013, 9:05 AM
  • leave only the ASan implementation for now
  • add a test
samsonov added inline comments.Dec 3 2013, 3:13 AM
lib/asan/asan_stack.cc
49

Can we instead use asan:: in sanitizer_print_stack_trace (and probably in GET_STACK_TRACE_) macro expansions?

lib/asan/lit_tests/TestCases/print-stack-trace.cc
3

I think you may just leave -O0 and -O3 here.

17

Remove trailing .*

earthdok added inline comments.Dec 3 2013, 3:59 AM
lib/asan/asan_stack.cc
49

Let's not bloat the macros with this. How about a scoped using directive as a compromise?

lib/asan/lit_tests/TestCases/print-stack-trace.cc
3

done

17

done

earthdok updated this revision to Unknown Object (????).Dec 3 2013, 4:00 AM
  • address samsonov's comments
samsonov accepted this revision.Dec 3 2013, 6:33 AM

LGTM

earthdok closed this revision.Dec 5 2014, 9:38 AM