Also make important events in init's life NOTICE rather than INFO,
and ensure that NOTICE events actually make it to the kernel log.
Also fix the logging so that if you have a printf format string
error, the compiler now catches it.
Also give messages from init, ueventd, and watchdogd distinct tags.
(Previously they'd all call themselves "init", and dmesg doesn't
include pids, so you couldn't untangle them.)
Also include the tag in SELinux messages.
Bug: 19544788
Change-Id: Ica6daea065bfdb80155c52c0b06f346a7df208fe
This change defines atrace_* functions for the host that act as
no-ops, which makes it easier to add tracing in ART.
Change-Id: I89397e83986686a2b6a6f245c25017eb379081b1
This was supposedly used to enable logging when !HAVE_ANDROID_OS
but it's only used in a file that's target specific.
Change-Id: Id83f2597e48a66b4821fc3b1237e212872b909fb
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>
Not seeding this each call should help reduce collisions when multiple
threads are calling ashmem_create_region. Also cleaned up code by
deleting gotos, and making formatting consistent.
Bug: 15394258
Change-Id: Iafdaea57b2317e0eb7c40d7b5595c523814fd88c
In some condition, some of FS would set disable_roll_forward option.
In this case, when we do power off or reboot, the power down progress
would stuck at android_reboot for 360 sec.
The reason is, remount_ro_done function check key word "rw" to determine
whether all the read-write FS has been remounted as read-only FS.
Unfortunately, it takes disable_roll_forward as a rw flag too by
mistake, so the check would always fail, until reach 360 sec threshold.
The patch would match "rw," from mount options, this can avoid the issue
successfully.
Change-Id: I409f9dc88c9ee5cf049615ea9dcccaf195b6bc5a
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
After a disconnect, the initial blocking connect takes
a long time to return, while subsequent calls return
quicks. Switch to a non-blocking connect to make the
re-connect time more consistent and faster overall.
Change-Id: I21d02b22a8eb9a457c2f1fa95eb17894d5612ccd
Signed-off-by: Ken Lierman <ken.lierman@windriver.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Reviewed-by: Jovanovic, Radivoje <radivoje.jovanovic@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
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
Adds Silvermont specific cache sizes for memset16/32 SSE optimization.
Change-Id: Ib5ea086d57544e74ac384ee1ef516b8511392f70
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
* 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
Change-Id: Ifd42911f93e17da09e6ff1298e8875e02f3b6608
A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.
str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.
But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!
It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.
Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f
