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
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
Packets captured and logged by the NFLOG target are unicast, so
extend to catch and decode them. To avoid escaping issues, the raw
contents are passed around as hex strings.
Bug: 18335678
Change-Id: Ib7299500baa00080a1f000f9da843eb527363353
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
Change-Id: I85053b8dcfe6224e2b64b4d8f7f2ef448b3cda34
This means that code that uses libcutils no longer has to ensure that
it's set ANDROID_SMP in the calling code's Android.mk for this to
function correctly.
Change-Id: I80c7ff170cd621106f34d6b74689d6b4f03e4eb7
The static libcutils tests cannot be built when using libc++ because
there are multiple symbol definition errors between libc++ and libgcc.
Bug: 18389856
Change-Id: I6f41c561f97b3a37477f844e9abf6551524a0fa3
This should not be committed until win_sdk and aarch64 builds are
fixed in the presence of this CL.
This reverts commit 2789faabfa.
We additionally remove uniprocessor support from the earlier CL,
thus avoiding a potential compiler code reordering issue.
Change-Id: I7207a5ca2efa907a6f757f172d7090a62b2311fe
The build system is still linking both libgcc and libcompiler-rt,
which is causing duplicate symbol errors on some architectures. This
requires a fix in the build system, so reverting for now.
This reverts commit e3cccbfd47.
When atrace_* functions are inlined,
the rarely used 1024-byte buffers are allocated on stack.
BUG: 17444504
Change-Id: I773512aeb70e8b79f3803c6d59cba064d2aa65b6
All kernel services will now be in the same cgroup as
foreground applications. This will now make kernel threads
not implicitly higher priority than android foreground
services.
Bug 17681097
Change-Id: I28e81c7aade50428d5395df86f00ce01c1e7af02
Replace atomic-inl.h with a file that just includes atomic.h.
Remove platform specific implementations.
Change-Id: If16d74fbe0af7836ed8c1296c17e13a2d0d20f64
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
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
Change-Id: Icf123a6f4508b1aeec073663aa1a0ceae5380aa1
Use expected inline behavior with clang.
GCC defaults to -std=gnu90, giving C89 inline semantics with GNU
extensions. Clang defaults to C99. Explicitly use gnu90.
Mark an unused parameter as __unused.
Fix some incorrect casts.
Change-Id: I05b95585d5e3688eda71769b63b6b8a9237bcaf4
Bug: 16408818
These targets are no longer in use, since we have a proper way to create both
32-bit and 64-bit host libraries in a single build now.
Cherry-pick from AOSP: 03cc1f747c
Change-Id: Icd09f795acd220de5b5e956a8d8e1b4ab4864fa9
Bug: 16408818
These targets are no longer in use, since we have a proper way to create both
32-bit and 64-bit host libraries in a single build now.
Change-Id: Icd09f795acd220de5b5e956a8d8e1b4ab4864fa9
* Read out system properties with same syntax as SystemProperties.java
* Also adds unit test suite to validate correctness of properties
* Also fixes buffer overrun in property_get
(cherry picked from commit d4507e9246)
Change-Id: Ifd42911f93e17da09e6ff1298e8875e02f3b6608
Don't follow symlinks. Suggestion from Jann Horn.
Also, add O_CLOEXEC. This prevents file descriptor leakage should
this code ever run in a multithreaded environment.
I'm not sure if either of these changes actually address any
security concerns, but it's harmless, so go ahead and add it.
Bug: 15675141
Change-Id: I7ba4e9d10439b7150f59759b54e3ad8ccba411e3
Port libcutils memset16/32 assembly SSE2 optimizations to x86_64
architecture. Ensures the same performance on 64-bit arch.
Change-Id: I874a71a884c0d28a152933ddff9cb886c9a6e99e
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
Andreas Gampe