Dump some memory at addresses for all registers that look like they
might have valid addresses. Previously this was only done for PC
and LR.
(This is expected to be disabled before ship.)
Bug 5484924
Change-Id: I9802eaa396783e1286ae0c53eaf2473892c38a02
When the tombstones are uploaded to APR, they're truncated at 64KB.
This causes the log data, which is at the end, to be lost if the
process has more than about 12 threads (which many do).
This change adds the last few lines of the log right below the
report for the crashing thread, where we should be guaranteed to
keep it.
Also, clean up trailing newlines on log messages (which end up in
the tombstone), and don't print a "------- log" banner if there
aren't any messages in that log file (e.g. slog).
Also also, don't try to show_nearby_maps unless this is the crashing
thread.
Bug 5471955
Change-Id: Iaa4fd2fafbaeda2f20bb95f202177d7744a91f9d
This makes two changes:
(1) Display ASCII values next to the memory dumps. For example:
I DEBUG: 00008ac4 706f6f4c 20676e69 74206425 73656d69 Looping %d times
I DEBUG: 00008ad4 7453000a 6e69726f 6f742067 0a702520 ..Storing to %p.
I DEBUG: 00008ae4 65642f00 657a2f76 55006f72 6c62616e ./dev/zero.Unabl
(The hex values are still displayed as little-endian word values, while
the ASCII part is byte oriented.)
(2) Optionally display memory dumps for all registers, not just LR
and PC, for the crashing thread. This is meant for situations where
we crash dereferencing foo->bar and want to see what the memory near
"foo" looks like -- could be handy if it got stomped by MUTF-16 text
or something recognizable.
Change #2 is currently disabled, via a compile-time setting.
Bug 5471955
Change-Id: Iacfd01c314055bad81db2f43b7d239f10086fcfb
This adds some additional output to native crashes. For example, if
something tried to access a bit of mmap(/dev/zero) memory that had
been mprotect()ed, you might see output like this:
I DEBUG : memory map around addr 4015a00c:
I DEBUG : 40159000-4015a000 /system/lib/libstdc++.so
I DEBUG : 4015a000-40162000 /dev/zero
I DEBUG : b0001000-b0009000 /system/bin/linker
The idea is to see what's in and around the fault address to make it
easier to identify bus errors due to file truncation and segmentation
faults caused by buffer over/underruns.
No output is generated for accesses below 0x1000 (which are likely
NULL pointer dereferences) or for signals that don't set si_addr.
Also, suppress the fault address for signals that don't set si_addr:
I DEBUG : signal 6 (SIGABRT), code 0 (?), fault addr --------
We still print "fault addr" followed by 8 characters for anything
that is parsing the contents. The "address" shown for signals like
SIGABRT was meaningless and possibly confusing.
Bug 5358516
Change-Id: Icae8ef309ea2d89b129f68d30f96b2ca8a69cc6c
The delta between start and end pointers in memory dump has to be
multiples of 4 or 16.
Bug: 3486787
Change-Id: Ie34aa79ffb704ca647805dbc6a16f2c35adf849c
The structure user_vfp is incorrectly defined in bionic/libc/kernel/arch-arm/asm/ptrace.h
at the moment, while it should be under bionic/libc/kernel/arch-arm/asm/user.h instead.
Before moving its definition in the corresponding source files, we need to fix its users.
It happens that debuggerd is the only one for now, so fix this by including <linux/user.h>
instead (which will include <asm/user.h> and <asm/ptrace.h>).
Also, make the debug output less chatty by specifying all symbols to be listed
through XLOG2 instead of XLOG.
Change-Id: I16e0fa700945d86efd44ee885a84ad609c0a9b58
