Allow SIGABRT to abort the program.

SIGABRT can be generated internally, usually by calling abort(),
or externally by another process.  When the signal is generated
by the kernel, info->si_pid is 0 and the signal is treated in the
same way as an exception (SIGSEGV, etc.), but the assumption
that the exception happens again upon return from the handler
is wrong, so we must have a special case for this.

Original CL: https://breakpad.appspot.com/734002/

BUG=chromium:303075
TEST=tested with Alt-VolumeUp-X on Chrome OS
A=semenzato@chromium.org
R=semenzato@google.com

Review URL: https://breakpad.appspot.com/754002

git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1233 4c0a9323-5329-0410-9bdc-e9ce6186880e
This commit is contained in:
thestig@chromium.org 2013-11-07 22:50:13 +00:00
parent fd9f3d8b17
commit 46821f78b1

View File

@ -341,10 +341,11 @@ void ExceptionHandler::SignalHandler(int sig, siginfo_t* info, void* uc) {
pthread_mutex_unlock(&handler_stack_mutex_);
if (info->si_pid) {
if (info->si_pid || sig == SIGABRT) {
// This signal was triggered by somebody sending us the signal with kill().
// In order to retrigger it, we have to queue a new signal by calling
// kill() ourselves.
// kill() ourselves. The special case (si_pid == 0 && sig == SIGABRT) is
// due to the kernel sending a SIGABRT from a user request via SysRQ.
if (tgkill(getpid(), syscall(__NR_gettid), sig) < 0) {
// If we failed to kill ourselves (e.g. because a sandbox disallows us
// to do so), we instead resort to terminating our process. This will