17e6a98b48
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