- create a structure to depict the private header
expected at logd end of socket.
- utilize this new structure instead of unscalable
byte stream technique used to unpack in logd.
Change-Id: I2d0e5c3531c279f2dc1fbd74807210ff8d804de0
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
system/core/include/utils/Mutex.h:134:25: error: non-constant-expression
cannot be narrowed from type 'long long' to '__kernel_time_t' (aka
'long') in initializer list [-Wc++11-narrowing]
system/core/include/utils/Mutex.h:135:26: error: non-constant-expression
cannot be narrowed from type 'long long' to 'long' in initializer list
[-Wc++11-narrowing]
Change-Id: Icb9df26aeb01617da5ab1c36987289f7c2b11954
This is not available for host builds because OSX doesn't have
pthread_mutex_timedlock() or equivalent.
Bug: 18842510
Change-Id: I072e74ab1a6f770fd245828b39c5f954dda1113b
The ANDROID_SINGLETON_STATIC_INSTANCE is used in some files
out of the android namespace. If it does not use full qualified
names, users of this macro will need to use it inside the 'android'
namespace to avoid warnings from clang compiler.
Change-Id: Ie4d4ba2b57fdc72d0deb3b7c2326304a44a1300f
This should probably be in libcutils instead, so code that needs to
care about Windows can use readv/writev.
Change-Id: I7c2ceec3f742cee0e44f69fd4c88459376bd0e08
As well intentioned as these were, uint16_t and C++11's char16_t are
_not_ actually compatible. They are not implicitly convertible, and
they mangle differently, so they are not even ABI compatible. In our
now wonderous world of C++11, no one should be using these, so just
kill them.
Bug: 18300613
Change-Id: I06d92d7f1d937dd94a620874323d4c50eb6a31bd
Needed for cases where something should be constexpr if possible, but
not being constexpr is fine if in pre-C++11 code (such as a const
static float member variable).
Bug: 18466763
Change-Id: I635d062575ba2fbc4cbe3a89f730128c404d95e1
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
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
Files that included FileMap.h (possibly transitively), before including
ByteOrder.h (which pulls in winsock2.h directly), will experience a
compiler warning/error from the latest mingw headers. This happens because
the headers require that winsock2.h come before windows.h in all cases.
The simplest (and most error-proof) fix for now is to include winsock2.h
before this use of windows.h.
Change-Id: I33069e4c9962d9820d0ea5976554f89d7ff6307c
libc++ also defines these types for pre-C++11, and the two definitions
need to match to avoid redefinition errors.
Bug: 18300613
Change-Id: I1e9198d39f7c470f37bc6edba2dca2d499f54c9b
Also:
- add kPreInitiliazed state to native bridge with check transition:
kOpened->kPreInitialized->kInitialized
- made sure we free the memory for the code_cache_path
- tidy up some error messages
- tidy up tests
- add a dummy native bridge to test with
Bug: 18027433
Bug: 18097480
Change-Id: I39f74c93580f2e224080dd3df2ffaa9cf9f8cd9c
When atrace_* functions are inlined,
the rarely used 1024-byte buffers are allocated on stack.
BUG: 17444504
Change-Id: I773512aeb70e8b79f3803c6d59cba064d2aa65b6
Replace atomic-inl.h with a file that just includes atomic.h.
Remove platform specific implementations.
Change-Id: If16d74fbe0af7836ed8c1296c17e13a2d0d20f64
Add a method to set up /proc/cpuinfo with enough privileges. Set
up the environment for an app in InitializeNativeBridge().
Turn on -Wall for libnativebridge.
Change-Id: I0b93da93251c6b4638de786bf98cf99df07c3fc2
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
