2009-03-04 04:28:35 +01:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2008 The Android Open Source Project
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* * Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* * Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
|
|
|
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
|
|
|
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
|
|
|
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
|
|
|
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
|
|
|
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
|
|
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
|
|
|
|
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2012-10-30 01:37:13 +01:00
|
|
|
#include "linker.h"
|
|
|
|
|
2013-07-17 22:33:19 +02:00
|
|
|
#include <errno.h>
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
#include <inttypes.h>
|
2013-07-17 22:33:19 +02:00
|
|
|
#include <signal.h>
|
2009-03-04 04:28:35 +01:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
2013-07-17 22:33:19 +02:00
|
|
|
#include <sys/mman.h>
|
2012-03-07 18:04:18 +01:00
|
|
|
#include <sys/prctl.h>
|
2009-03-04 04:28:35 +01:00
|
|
|
#include <sys/socket.h>
|
2010-06-11 03:29:33 +02:00
|
|
|
#include <sys/un.h>
|
2013-07-17 22:33:19 +02:00
|
|
|
#include <unistd.h>
|
2009-03-04 04:28:35 +01:00
|
|
|
|
2012-10-30 01:37:13 +01:00
|
|
|
extern "C" int tgkill(int tgid, int tid, int sig);
|
2009-03-04 04:28:35 +01:00
|
|
|
|
2014-02-01 01:56:39 +01:00
|
|
|
#if __LP64__
|
|
|
|
#define DEBUGGER_SOCKET_NAME "android:debuggerd64"
|
|
|
|
#else
|
2012-06-07 03:37:48 +02:00
|
|
|
#define DEBUGGER_SOCKET_NAME "android:debuggerd"
|
2014-02-01 01:56:39 +01:00
|
|
|
#endif
|
2012-06-07 03:37:48 +02:00
|
|
|
|
2012-10-30 01:37:13 +01:00
|
|
|
enum debugger_action_t {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
// dump a crash
|
|
|
|
DEBUGGER_ACTION_CRASH,
|
|
|
|
// dump a tombstone file
|
|
|
|
DEBUGGER_ACTION_DUMP_TOMBSTONE,
|
|
|
|
// dump a backtrace only back to the socket
|
|
|
|
DEBUGGER_ACTION_DUMP_BACKTRACE,
|
2012-10-30 01:37:13 +01:00
|
|
|
};
|
2012-06-07 03:37:48 +02:00
|
|
|
|
|
|
|
/* message sent over the socket */
|
2012-10-30 01:37:13 +01:00
|
|
|
struct debugger_msg_t {
|
2013-04-04 22:46:46 +02:00
|
|
|
// version 1 included:
|
|
|
|
debugger_action_t action;
|
|
|
|
pid_t tid;
|
|
|
|
|
|
|
|
// version 2 added:
|
|
|
|
uintptr_t abort_msg_address;
|
2014-04-26 01:02:00 +02:00
|
|
|
|
|
|
|
// version 3 added:
|
|
|
|
int32_t original_si_code;
|
2012-10-30 01:37:13 +01:00
|
|
|
};
|
2009-10-16 21:13:34 +02:00
|
|
|
|
2012-03-07 18:04:18 +01:00
|
|
|
// see man(2) prctl, specifically the section about PR_GET_NAME
|
|
|
|
#define MAX_TASK_NAME_LEN (16)
|
2010-06-11 03:29:33 +02:00
|
|
|
|
2012-10-30 01:37:13 +01:00
|
|
|
static int socket_abstract_client(const char* name, int type) {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
sockaddr_un addr;
|
|
|
|
|
|
|
|
// Test with length +1 for the *initial* '\0'.
|
|
|
|
size_t namelen = strlen(name);
|
|
|
|
if ((namelen + 1) > sizeof(addr.sun_path)) {
|
|
|
|
errno = EINVAL;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is used for abstract socket namespace, we need
|
|
|
|
// an initial '\0' at the start of the Unix socket path.
|
|
|
|
//
|
|
|
|
// Note: The path in this case is *not* supposed to be
|
|
|
|
// '\0'-terminated. ("man 7 unix" for the gory details.)
|
|
|
|
memset(&addr, 0, sizeof(addr));
|
|
|
|
addr.sun_family = AF_LOCAL;
|
|
|
|
addr.sun_path[0] = 0;
|
|
|
|
memcpy(addr.sun_path + 1, name, namelen);
|
|
|
|
|
|
|
|
socklen_t alen = namelen + offsetof(sockaddr_un, sun_path) + 1;
|
|
|
|
|
|
|
|
int s = socket(AF_LOCAL, type, 0);
|
|
|
|
if (s == -1) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int rc = TEMP_FAILURE_RETRY(connect(s, reinterpret_cast<sockaddr*>(&addr), alen));
|
|
|
|
if (rc == -1) {
|
|
|
|
close(s);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return s;
|
2010-06-11 03:29:33 +02:00
|
|
|
}
|
|
|
|
|
2011-07-29 21:46:34 +02:00
|
|
|
/*
|
2012-10-02 22:53:13 +02:00
|
|
|
* Writes a summary of the signal to the log file. We do this so that, if
|
|
|
|
* for some reason we're not able to contact debuggerd, there is still some
|
|
|
|
* indication of the failure in the log.
|
2011-07-29 21:46:34 +02:00
|
|
|
*
|
|
|
|
* We could be here as a result of native heap corruption, or while a
|
|
|
|
* mutex is being held, so we don't want to use any libc functions that
|
|
|
|
* could allocate memory or hold a lock.
|
|
|
|
*/
|
2013-07-17 22:33:19 +02:00
|
|
|
static void log_signal_summary(int signum, const siginfo_t* info) {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
const char* signal_name = "???";
|
|
|
|
bool has_address = false;
|
|
|
|
switch (signum) {
|
|
|
|
case SIGABRT:
|
|
|
|
signal_name = "SIGABRT";
|
|
|
|
break;
|
|
|
|
case SIGBUS:
|
|
|
|
signal_name = "SIGBUS";
|
|
|
|
has_address = true;
|
|
|
|
break;
|
|
|
|
case SIGFPE:
|
|
|
|
signal_name = "SIGFPE";
|
|
|
|
has_address = true;
|
|
|
|
break;
|
2014-05-17 01:59:54 +02:00
|
|
|
case SIGILL:
|
|
|
|
signal_name = "SIGILL";
|
|
|
|
has_address = true;
|
|
|
|
break;
|
|
|
|
case SIGPIPE:
|
|
|
|
signal_name = "SIGPIPE";
|
|
|
|
break;
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
case SIGSEGV:
|
|
|
|
signal_name = "SIGSEGV";
|
|
|
|
has_address = true;
|
|
|
|
break;
|
2012-07-31 21:07:22 +02:00
|
|
|
#if defined(SIGSTKFLT)
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
case SIGSTKFLT:
|
|
|
|
signal_name = "SIGSTKFLT";
|
|
|
|
break;
|
2012-07-31 21:07:22 +02:00
|
|
|
#endif
|
2014-05-17 01:59:54 +02:00
|
|
|
case SIGTRAP:
|
|
|
|
signal_name = "SIGTRAP";
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
char thread_name[MAX_TASK_NAME_LEN + 1]; // one more for termination
|
|
|
|
if (prctl(PR_GET_NAME, (unsigned long)thread_name, 0, 0, 0) != 0) {
|
|
|
|
strcpy(thread_name, "<name unknown>");
|
|
|
|
} else {
|
|
|
|
// short names are null terminated by prctl, but the man page
|
|
|
|
// implies that 16 byte names are not.
|
|
|
|
thread_name[MAX_TASK_NAME_LEN] = 0;
|
|
|
|
}
|
|
|
|
|
2014-08-29 21:02:36 +02:00
|
|
|
// "info" will be null if the siginfo_t information was not available.
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
// Many signals don't have an address or a code.
|
|
|
|
char code_desc[32]; // ", code -6"
|
|
|
|
char addr_desc[32]; // ", fault addr 0x1234"
|
|
|
|
addr_desc[0] = code_desc[0] = 0;
|
2014-08-29 21:02:36 +02:00
|
|
|
if (info != nullptr) {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
// For a rethrown signal, this si_code will be right and the one debuggerd shows will
|
|
|
|
// always be SI_TKILL.
|
2014-08-27 05:48:11 +02:00
|
|
|
__libc_format_buffer(code_desc, sizeof(code_desc), ", code %d", info->si_code);
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
if (has_address) {
|
2014-08-27 05:48:11 +02:00
|
|
|
__libc_format_buffer(addr_desc, sizeof(addr_desc), ", fault addr %p", info->si_addr);
|
2012-10-02 22:53:13 +02:00
|
|
|
}
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
}
|
|
|
|
__libc_format_log(ANDROID_LOG_FATAL, "libc",
|
|
|
|
"Fatal signal %d (%s)%s%s in tid %d (%s)",
|
|
|
|
signum, signal_name, code_desc, addr_desc, gettid(), thread_name);
|
2011-07-29 21:46:34 +02:00
|
|
|
}
|
|
|
|
|
2012-10-02 22:53:13 +02:00
|
|
|
/*
|
|
|
|
* Returns true if the handler for signal "signum" has SA_SIGINFO set.
|
|
|
|
*/
|
2013-07-17 22:33:19 +02:00
|
|
|
static bool have_siginfo(int signum) {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
struct sigaction old_action, new_action;
|
|
|
|
|
|
|
|
memset(&new_action, 0, sizeof(new_action));
|
|
|
|
new_action.sa_handler = SIG_DFL;
|
|
|
|
new_action.sa_flags = SA_RESTART;
|
|
|
|
sigemptyset(&new_action.sa_mask);
|
|
|
|
|
|
|
|
if (sigaction(signum, &new_action, &old_action) < 0) {
|
|
|
|
__libc_format_log(ANDROID_LOG_WARN, "libc", "Failed testing for SA_SIGINFO: %s",
|
|
|
|
strerror(errno));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
bool result = (old_action.sa_flags & SA_SIGINFO) != 0;
|
|
|
|
|
2014-08-29 21:02:36 +02:00
|
|
|
if (sigaction(signum, &old_action, nullptr) == -1) {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
__libc_format_log(ANDROID_LOG_WARN, "libc", "Restore failed in test for SA_SIGINFO: %s",
|
|
|
|
strerror(errno));
|
|
|
|
}
|
|
|
|
return result;
|
2012-10-02 22:53:13 +02:00
|
|
|
}
|
|
|
|
|
2014-04-26 01:02:00 +02:00
|
|
|
static void send_debuggerd_packet(siginfo_t* info) {
|
2014-07-23 22:56:23 +02:00
|
|
|
if (prctl(PR_GET_DUMPABLE, 0, 0, 0, 0) == 0) {
|
|
|
|
// process has disabled core dumps and PTRACE_ATTACH, and does not want to be dumped.
|
|
|
|
// Honor that intention by not connecting to debuggerd and asking it
|
|
|
|
// to dump our internal state.
|
|
|
|
__libc_format_log(ANDROID_LOG_INFO, "libc",
|
|
|
|
"Suppressing debuggerd output because prctl(PR_GET_DUMPABLE)==0");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-26 01:02:00 +02:00
|
|
|
int s = socket_abstract_client(DEBUGGER_SOCKET_NAME, SOCK_STREAM);
|
|
|
|
if (s == -1) {
|
|
|
|
__libc_format_log(ANDROID_LOG_FATAL, "libc", "Unable to open connection to debuggerd: %s",
|
|
|
|
strerror(errno));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// debuggerd knows our pid from the credentials on the
|
|
|
|
// local socket but we need to tell it the tid of the crashing thread.
|
|
|
|
// debuggerd will be paranoid and verify that we sent a tid
|
|
|
|
// that's actually in our process.
|
|
|
|
debugger_msg_t msg;
|
|
|
|
msg.action = DEBUGGER_ACTION_CRASH;
|
|
|
|
msg.tid = gettid();
|
2014-05-14 19:02:03 +02:00
|
|
|
msg.abort_msg_address = reinterpret_cast<uintptr_t>(g_abort_message);
|
2014-08-29 21:02:36 +02:00
|
|
|
msg.original_si_code = (info != nullptr) ? info->si_code : 0;
|
2014-04-26 01:02:00 +02:00
|
|
|
int ret = TEMP_FAILURE_RETRY(write(s, &msg, sizeof(msg)));
|
|
|
|
if (ret == sizeof(msg)) {
|
|
|
|
char debuggerd_ack;
|
|
|
|
ret = TEMP_FAILURE_RETRY(read(s, &debuggerd_ack, 1));
|
|
|
|
int saved_errno = errno;
|
|
|
|
notify_gdb_of_libraries();
|
|
|
|
errno = saved_errno;
|
|
|
|
} else {
|
|
|
|
// read or write failed -- broken connection?
|
|
|
|
__libc_format_log(ANDROID_LOG_FATAL, "libc", "Failed while talking to debuggerd: %s",
|
|
|
|
strerror(errno));
|
|
|
|
}
|
|
|
|
|
|
|
|
close(s);
|
|
|
|
}
|
|
|
|
|
2011-07-29 21:46:34 +02:00
|
|
|
/*
|
|
|
|
* Catches fatal signals so we can ask debuggerd to ptrace us before
|
|
|
|
* we crash.
|
|
|
|
*/
|
2014-04-26 01:02:00 +02:00
|
|
|
static void debuggerd_signal_handler(int signal_number, siginfo_t* info, void*) {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
// It's possible somebody cleared the SA_SIGINFO flag, which would mean
|
|
|
|
// our "info" arg holds an undefined value.
|
|
|
|
if (!have_siginfo(signal_number)) {
|
2014-08-29 21:02:36 +02:00
|
|
|
info = nullptr;
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
log_signal_summary(signal_number, info);
|
|
|
|
|
2014-04-26 01:02:00 +02:00
|
|
|
send_debuggerd_packet(info);
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
|
|
|
|
// Remove our net so we fault for real when we return.
|
|
|
|
signal(signal_number, SIG_DFL);
|
|
|
|
|
|
|
|
// These signals are not re-thrown when we resume. This means that
|
|
|
|
// crashing due to (say) SIGPIPE doesn't work the way you'd expect it
|
|
|
|
// to. We work around this by throwing them manually. We don't want
|
2014-04-26 01:02:00 +02:00
|
|
|
// to do this for *all* signals because it'll screw up the si_addr for
|
|
|
|
// faults like SIGSEGV. It does screw up the si_code, which is why we
|
|
|
|
// passed that to debuggerd above.
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
switch (signal_number) {
|
|
|
|
case SIGABRT:
|
|
|
|
case SIGFPE:
|
|
|
|
case SIGPIPE:
|
2013-10-26 02:38:02 +02:00
|
|
|
#if defined(SIGSTKFLT)
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
case SIGSTKFLT:
|
2012-07-31 21:07:22 +02:00
|
|
|
#endif
|
2014-05-17 02:34:13 +02:00
|
|
|
case SIGTRAP:
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
tgkill(getpid(), gettid(), signal_number);
|
|
|
|
break;
|
|
|
|
default: // SIGILL, SIGBUS, SIGSEGV
|
|
|
|
break;
|
|
|
|
}
|
2009-03-04 04:28:35 +01:00
|
|
|
}
|
|
|
|
|
2014-04-26 01:02:00 +02:00
|
|
|
__LIBC_HIDDEN__ void debuggerd_init() {
|
Make libc signal handler output more like debuggerd.
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
2014-04-19 02:39:25 +02:00
|
|
|
struct sigaction action;
|
|
|
|
memset(&action, 0, sizeof(action));
|
|
|
|
sigemptyset(&action.sa_mask);
|
|
|
|
action.sa_sigaction = debuggerd_signal_handler;
|
|
|
|
action.sa_flags = SA_RESTART | SA_SIGINFO;
|
|
|
|
|
|
|
|
// Use the alternate signal stack if available so we can catch stack overflows.
|
|
|
|
action.sa_flags |= SA_ONSTACK;
|
|
|
|
|
2014-08-29 21:02:36 +02:00
|
|
|
sigaction(SIGABRT, &action, nullptr);
|
|
|
|
sigaction(SIGBUS, &action, nullptr);
|
|
|
|
sigaction(SIGFPE, &action, nullptr);
|
|
|
|
sigaction(SIGILL, &action, nullptr);
|
|
|
|
sigaction(SIGPIPE, &action, nullptr);
|
|
|
|
sigaction(SIGSEGV, &action, nullptr);
|
2012-07-31 21:07:22 +02:00
|
|
|
#if defined(SIGSTKFLT)
|
2014-08-29 21:02:36 +02:00
|
|
|
sigaction(SIGSTKFLT, &action, nullptr);
|
2012-07-31 21:07:22 +02:00
|
|
|
#endif
|
2014-08-29 21:02:36 +02:00
|
|
|
sigaction(SIGTRAP, &action, nullptr);
|
2009-03-04 04:28:35 +01:00
|
|
|
}
|