History log of /system/core/debuggerd/utility.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
053b865412d1982ad1dc0e840898d82527deeb99 07-Jun-2012 Jeff Brown <jeffbrown@google.com> Enhance native stack dumps.

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

Only root or system server can request to dump backtraces but
only root can dump tombstones.

Bug: 6615693
Change-Id: Ib3edcc16f9f3a687e414e3f2d250d9500566123b
19b39f371be5250e7b9e88016be1e5e665367b3f 22-Nov-2011 Jeff Brown <jeffbrown@google.com> Improve backtrace formatting.

Show the symbol offset, when available.

Centralized formatting of native stack traces in libcorkscrew.
It's handy for automated tools if all stacks look the same.
Since we already made them all look them same, we might as well
do the formatting in just one place.

Do not strip the Thumb bit on ARM. This fixes an off-by-one
issue that could happen when resolving a PC that was at the
very beginning of a Thumb function, since the symbol table would
have the Thumb bit set but since we stripped the bit from our
PC, we would be looking for an address one byte before the
one listed in the symbol table. It's also quite useful to see
whether a given function is executing in Thumb mode just by glancing
at the PC.

Change-Id: Icaa29add85ce0bcafe24d5ce2098e138d809e2ab
f0c5872637a63e28e3cd314cfc915c07f76df9c6 04-Nov-2011 Jeff Brown <jeffbrown@google.com> Improve stack unwinder robustness.

Keep track of whether memory maps are readable. Use the information
in try_get_word to try to avoid accidentally dereferencing an invalid
pointer within the current process. (Note that I haven't ever
seen that happen during normal unwinding, but it pays to be
a little more careful.)

Refactored try_get_word a little to make it easier to pass it the
needed state for validation checks by way of a little memory_t struct.

Improved how the memory map for the current process is cached. This is
important because we need up to date information about readable maps.
Use a 5 second cache expiration.

Improved the PC -> LR fallback logic in the unwinder so we can
eke out an extra frame sometimes.

Fixed a bug reading ELF program headers. The phnum & phentsize
fields are half-words. We were incorrectly interpreting
phnum as a whole word.

Used android_atomic_* operations carefully in the unwinder
to prevent possible memory races between the dumper and the dumpee.
This was highly unlikely (or even impossible due to the presence
of other barriers along the way) but the code is clearer now about
its invariants.

Fixed a bug in debuggerd where the pid was being passed to have
its stack dump taken instead of the tid, resulting in short
stacks because ptrace couldn't read the data if pid != tid.
Did a full sweep to ensure that we use pid / tid correctly everywhere.

Ported old code from debuggerd to rewind the program counter back
one instruction so that it points to the branch instruction itself
instead of the return address.

Change-Id: Icc4eb08320052975a4ae7f0f5f0ac9308a2d33d7
13e715b491e876865e752a3a69dd6f347049a488 21-Oct-2011 Jeff Brown <jeffbrown@google.com> Use libcorkscrew in debuggerd.

Change-Id: I5e3645a39d96c808f87075b49111d0262a19a0c8
136dcc5ce628a1ba600a6818e5cb24d5f15eb016 23-Sep-2011 Andy McFadden <fadden@android.com> Show maps near native fault address

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
6cc492308712613cd23bee9240b1757428841a2f 14-Oct-2010 Bruce Beare <bruce.j.beare@intel.com> debuggerd: IA version

Change-Id: I0c0d9c2d7e476b8d117aaf505a9480a47c0b5c05
Signed-off-by: Lei Li <lei.l.li@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
849249064cae9c1bb23b0204b5d35b832567801e 13-Oct-2010 Bruce Beare <bruce.j.beare@intel.com> debuggerd: Reorganize to facilitate IA commit

Change-Id: I22dd02daf617672fc0a8ba7e396017c57f17e26e
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
dd7bc3319deb2b77c5d07a51b7d6cd7e11b5beb0 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
e54eebbf1a908d65ee8cf80bab62821c05666d70 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
35237d135807af84bf9b0e5b8d7f8633e58db6f5 18-Dec-2008 The Android Open Source Project <initial-contribution@android.com> Code drop from //branches/cupcake/...@124589
4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution