The problem is that without SA_RESTORER flag, kernel ignores the handler. So tracer actually did not setup any handler.
Add SA_RESTORER flag when setting up handlers.
Add a test that causes SIGSEGV in stoptheworld callback.
Move SignalContext from asan to sanitizer_common to print better diagnostics about signal in the tracer thread.
http://reviews.llvm.org/D8005
llvm-svn: 230978
Summary:
AsanOnSIGSEGV has some heuristics for detecting stack overflow, but
they don't cope with a PowerPC store-with-update instruction which
modifies sp and stores to the modified address in one instruction.
This patch adds some PowerPC-specific code to check for this case.
This fixes the last few cases of the stack-overflow test.
Reviewers: kcc, samsonov, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6253
llvm-svn: 222001
Summary:
Tweak the asan stack overflow heuristics to cope with PowerPC64 redzones,
which are larger than on x86-64: 288 bytes for big-endian and 512 bytes
for little-endian.
Reviewers: kcc, willschm, samsonov, eugenis
Reviewed By: samsonov, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6168
llvm-svn: 221578
Because of the way Bionic sets up signal stack frames, libc unwinder is unable
to step through it, resulting in broken SEGV stack traces.
Luckily, libcorkscrew.so on Android implements an unwinder that can start with
a signal context, thus sidestepping the issue.
llvm-svn: 201151
This change is a part of refactoring intended to have common signal handling behavior in all tools.
This particular CL moves InstallSignalHandlers() into sanitizer_common (making it InstallDeadlySignalHandlers()), but doesn't enable default signal handlers for any tool other than ASan.
llvm-svn: 200542
This change is a part of refactoring intended to have common signal handling behavior in all tools.
Note that this particular change doesn't enable use_sigaltstack support in every tool.
llvm-svn: 200310
Call AsanThread::Destroy() from a late-running TSD destructor.
Previously we called it before any user-registered TSD destructors, which caused
false positives in LeakSanitizer.
llvm-svn: 192585
Currently ASan reports many kinds of errors, and the code that actually prints error messages can
be found inside allocator, OS-specific files, interceptors code etc.
An example of maintenance troubles this situation causes:
There is currently an ASan interface function that registers
callback which should take the char buffer with error report printed by ASan.
This function is now broken, as one has to insert callback calls to all the places in
ASan code where the error reports are printed, surprisingly it is not only
"__asan_report_error" function...
llvm-svn: 161568
Kostya Serebryany