suyu/breakpad
26
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Allow SIGABRT to abort the program.

Browse source 
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
1 changed files with 3 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
src/client/linux/handler/exception_handler.cc
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