Convert abort's inline_tgkill to do the equivalent of
pthread_sigqueue(pthread_self(), ...), so that we can use it in fdsan
as well.
Test: bionic-unit-tests
Test: debuggerd_test32
Test: debuggerd_test64
Change-Id: I92a7b84e2f00ce021b4043ed8a3bd8683d77fe9c
This doesn't address `struct sigaction` and `sigaction`. That will
come later.
Bug: http://b/72493232
Test: ran tests
Change-Id: I4134346757ce3a4dac6feae413361cec16223386
The main motivation here is that the sigprocmask in pthread_exit wasn't
actually blocking the real-time signals, and debuggerd (amongst other
things) is using them. I wasn't able to write a test that actually won
that race but I did write an equivalent one for posix_spawn.
This also fixes all the uses of sigset_t where the sigset_t isn't
exposed to the outside (which we can't easily fix because it would be
an ABI change).
Bug: https://issuetracker.google.com/72291624
Test: ran tests
Change-Id: Ib6eebebc5a7b0150079f1cb79593247917dcf750
With this, stack frame 0 is the abort, not tgkill.
arm:
#00 pc 0001a41c /system/lib/libc.so (abort+63)
arm64:
#00 pc 000000000001d75c /system/lib64/libc.so (abort+120)
Also "include what you use" for <sys/syscall.h>.
Bug: N/A
Test: ran `crasher abort` and `crasher64 abort`
Change-Id: I6517ac67b39b4133e890d52efc115071c812958b
Switch raise to using tgkill with direct syscalls of getpid/gettid,
and switch abort to use raise(SIGABRT).
Bug: http://b/37769298
Test: debuggerd_test
Change-Id: If6f9d17fd8ae6177e742dc9f2f44bd78539431ba
Some PoS internal system can't cope with more than 4 stack frames,
so the fact that our abort(3) implementation takes 4 frames by itself
makes it useless.
Re-reading POSIX, it only says "behaves as if", so the previous
implementation chain wasn't mandatory and we can just go straight to
calling tgkill...
Before:
#00 pc 0000000000069be4 /system/lib64/libc.so (tgkill+8)
#01 pc 0000000000066d50 /system/lib64/libc.so (pthread_kill+64)
#02 pc 0000000000028110 /system/lib64/libc.so (raise+24)
#03 pc 000000000001d4ec /system/lib64/libc.so (abort+52)
After:
#00 pc 0000000000069bc8 /system/lib64/libc.so (tgkill+8)
#01 pc 000000000001d4c8 /system/lib64/libc.so (abort+80)
#02 pc 0000000000001494 /system/xbin/crasher64 (_ZL9do_actionPKc+872)
#03 pc 00000000000010e0 /system/xbin/crasher64 (main+88)
This is less useful on 32-bit ARM because there there's an extra trampoline
from an assembler abort(3) implementation, so you'll still only get one
meaningful stack frame. But every other architecture will now get two!
But wait!
It turns out that the assembler hack isn't needed any more. Here we are
unwinding just fine all the way through the 32-bit ARM crasher:
Before (with direct call to tgkill but still using the assembler):
#00 pc 00049e7c /system/lib/libc.so (tgkill+12)
#01 pc 00019c6f /system/lib/libc.so (__libc_android_abort+50)
#02 pc 000181f8 /system/lib/libc.so (abort+4)
#03 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#04 pc 00017721 /system/lib/libc.so (__libc_init+48)
#05 pc 00000b38 /system/xbin/crasher (_start+96)
After:
#00 pc 00049e6c /system/lib/libc.so (tgkill+12)
#01 pc 00019c5f /system/lib/libc.so (abort+50)
#02 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#03 pc 00017721 /system/lib/libc.so (__libc_init+48)
#04 pc 00000b38 /system/xbin/crasher (_start+96)
(As you can see, the fact that we see __libc_init rather than main was true
with the assembler stub too, so that's not a regression even if it does seem
odd...)
Bug: N/A
Test: ran crasher64
Change-Id: I9dd5b214c495604c8b502c7ec0de3631080d8c29
* Register cleanup function with atexit
instead of calling it explicitly on
exit()
* abort() no longer calls _cleanup:
Flushing stdio buffers on abort is no
longer required by POSIX.
* dlmalloc no longer need to reset cleanup
(see above)
* Upstream findfp.c makebuf.c setvbuf.cexit.c
to openbsd versions.
Bug: 14415367
Change-Id: I277058852485a9d3dbb13e5c232db5f9948d78ac
* A dlmalloc usage error shouldn't call abort(3) because we want to
cause a SIGSEGV by writing the address dlmalloc didn't like to an
address the kernel won't like, so that debuggerd will dump the
memory around the address that upset dlmalloc.
* Switch to the simpler FreeBSD/NetBSD style of registering stdio
cleanup. Hopefully this will let us simplify more of the stdio
implementation.
* Clear the stdio cleanup handler before we abort because of a dlmalloc
corruption error. This fixes the reported bug, where we'd hang inside
dlmalloc because the stdio cleanup reentered dlmalloc.
Bug: 9301265
Change-Id: Ief31b389455d6876e5a68f0f5429567d37277dbc
