Commit graph

7 commits

Author SHA1 Message Date
Andreas Gampe
7f71a45a17 Libcutils: Remove unused variable
Change-Id: I95eed017e78468c4946b2a5b62b6fe92e256673e
2015-02-19 16:54:32 -08:00
Christopher Ferris
9774df6134 Move 32 bit/64 bit check into debuggerd.
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
2015-01-20 17:22:07 -08:00
Christopher Ferris
fa41e0f5c8 Add timed versions of stack dumping functions.
Under some unknown circumstances, debuggerd could become unresponsive.
If you try and take a bugreport during this time, it will hang forever.
Adding functions that have a timeout will allow dumpstate to stop if
dumping is taking too long.

Bug: 18766581

(cherry picked from commit 5f2ff6a910)

Change-Id: I39e8e9c60209e3ef9efac795fedb8e1edce2bd3e
2015-01-15 15:34:21 -08:00
Christopher Ferris
6bcc4acc6f Use the correct debuggerd given the tid.
On 64 bit systems, calling dump_backtrace_to_file will automatically
call debuggerd64. If the process to dump is actually 32 bit, this
creates an unrecognizable dump backtrace. Modify the code to check the
type of the process and connect to the appropriate debuggerd process.

This change refactors both the tombstone and backtrace functionality to
allow both to work properly on 64 bit systems when dealing with mixed
processes.

Bug: 17487122

(cherry picked from commit a9fa7b87f1)

Change-Id: I3c9e0212c8720877a6af092071a3695df2a36df8
2014-09-13 16:22:17 -07:00
Elliott Hughes
855fcc3114 Use the si_code value bionic passes us.
Bionic needs to re-raise various signals, which means the si_code
debuggerd sees has been clobbered. If bionic sends us the original
si_code value, we can use that instead of the one we see when the
ptrace the crashed process' siginfo.

Change-Id: If116a6bc667d55a6fb39b74f96673292af4e4c8c
2014-04-25 20:20:39 -07:00
Christopher Ferris
1da83c3ecc Init the abort_msg_address value.
When initiating a manual dump, the abort_msg_address parameter is random
garbage. Initialize this value to 0.

Change-Id: I9ba817ee6104f47cfcb2b746bfa6f02a259c86d7
2014-01-10 14:46:03 -08:00
Jeff Brown
053b865412 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
console.

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

Bug: 6615693
Change-Id: Ib3edcc16f9f3a687e414e3f2d250d9500566123b
2012-06-08 13:29:23 -07:00