The debuggerd code sometimes calls _LOG(..., logtype::ERROR, ...)
and sometimes ALOGE(). Standardize on ALOGE since the _LOG message
will wind up in the tombstone in weird places, but using ALOGE
will wind up in the logcat portion of the tombstone.
Bug: 21467089
Change-Id: Ie893f5e91d45b48ef3f5864c3a714e60ac848fb3
Previously, the map printing in tombstones for 64 bit devices uses
a variable length value. This means that the maps are not lined up.
The new format is to print the map as 00000000'00000000 in all ways.
Also fix a bug where the backtrace_map_t did not initialize all
parameters.
Add unit tests for all of the dump_all_maps function.
Bug: 20950813
Change-Id: I30901c8a0251b00d85c4c01476b033ef8db84e32
- Add dumping memory around registers for x86/x86_64.
- Add unit tests for new dump_memory function.
- Cleanup all of the machine.cpp files.
- Increase the high address check for 32 bit, and decrease the high
address allowed for 64 bit slightly to match mips64.
Bug: 21206576
Change-Id: I6f75141f3282db48b10f7c695a1cf2eb75a08351
For every map that has a name, and if it's a mapped in shared library,
print the build id.
Refactor the way dump_all_maps logs data.
Refactor the way stack segments are dumped.
Bug: 19371018
Change-Id: Ic08d05a4b13f128925743936fb84d8059f7cb56f
On 64 bit systems, calls to dump_backtrace_to_file or dump_tombstone
try and directly contact the correct debuggerd (32 bit vs 64 bit)
by reading the elf information for the executable.
Unfortunately, system_server makes a call to dump_backtrace_to_file
and it doesn't have permissions to read the executable data, so it
defaults to always contacting the 64 bit debuggerd.
This CL changes the code so that all dump requests go to the 64 bit
debuggerd, which reads the elf information and redirects requests for
32 bit processes to the 32 bit debuggerd.
Testing:
- Forced the watchdog code in system_server to dump stacks and
verified that all native stacks are dumped correctly.
- Verified that dumpstate and bugreport still properly dump the native
processes on a 64 bit and 32 bit system.
- Intentionally forced the 64 bit to 32 bit redirect to write only a
byte at a time and verified there are no errors, and no dropped data.
- Used debuggerd and debuggerd64 to dump 32 bit and 64 bit processes
seemlessly.
- Used debuggerd on a 32 bit system to dump native stacks.
Bug: https://code.google.com/p/android/issues/detail?id=97024
Change-Id: Ie01945153bdc1c4ded696c7334b61d58575314d1
There's no good reason to separate "fill the integer registers with
recognizable patterns and crash" from "fill the FP registers with recognizable
patterns and crash".
Also remove the incorrect use of ARCH_ARM_HAVE_VFP_D32 rather than try to fix
it.
Change-Id: I3a4a3aca1575de5489314027ae52168997404d79
Use LOCAL_MULTILIB to build multiple versions of executables
instead of manually creating two build rules.
Change-Id: I1a993ff7b5f527a88735f46eec9822bb97d16490
This is part 1, only including the bare minimum changes because
our diff tool doesn't easily show differences when a file moves. This
also breaks it into a small chunk in case some other changes break things,
as unlikely as I think that will be.
Change-Id: Ib7a3e7a2cc1ac574d15b65fda23813ebcf5d31af
Remove all of the code in debuggerd that uses libcorkscrew directly
and replace with libbacktrace.
Also do a bit of refactoring to clean up some functions that were
passing around variables that weren't used.
Bug: 8410085
Change-Id: I27da4fbe3f12ce38a85b4432fc1119984c9c391b
bionic's __stack_chk_fail was preventing debuggerd from dumping
stacks, which was not helpful.
Bug: 2487269
Change-Id: Idba2a274037b960dfb2ac1c21686323268c4b372
Restore the security contexts of tombstone directory
when initially created.
Change-Id: I25b53730991576eccb62ca57050decd584acc639
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Provides a new mechanism for dumpstate (while running as root)
to request that debuggerd dump the stacks of native processes that
we care about in bug reports. In this mode, the backtrace
is formatted to look similar to a Dalvik backtrace.
Moved the tombstone generating code into a separate file to
make it easier to maintain.
Fixed a bug where sometimes the stack traces would be incomplete
because we were not waiting for each thread to stop after issuing
PTRACE_ATTACH, only the main thread. So sometimes we were missing
traces for some threads.
Refactored the logging code to prevent accidentally writing data
to logcat when explicitly dumping a tombstone or backtrace from the
console.
Only root or system server can request to dump backtraces but
only root can dump tombstones.
Bug: 6615693
Change-Id: Ib3edcc16f9f3a687e414e3f2d250d9500566123b
This change enables debuggerd to provide backtraces with function
names in tombstone files and log messages. It does this by reading
the image file that the address is found in, and parsing the dynamic
symbol table to try to extract the symbol corresponding to the given
address.
This works best when "-Wl,-export-dynamic" is added to the LDFLAGS
of each library and executable, because this will cause all symbols
to be added to the dynamic symbol table. If this flag is not present,
it will still work, but it will only be able to identify functions
which are part of the external API of the library/executable.
Change-Id: I618baaff9ed9143b7d1a1f302224e9f21d2b0626
