This test only works if you're root (strictly: if you have permission to
CLONE_NEWNS), so it's useful to us when we're doing ad hoc testing (since
that's usually done as root), but it's not useful as part of CTS or when
running the tests on the host.
(cherry-pick of 84d0683a824fa02dbaa6d1b56a79223804b54e80.)
Bug: 16705621
Bug: 17170200
Change-Id: Ia92c871b15f7e45fc174bb59bc95540fd00ae745
This test only works if you're root (strictly: if you have permission to
CLONE_NEWNS), so it's useful to us when we're doing ad hoc testing (since
that's usually done as root), but it's not useful as part of CTS or when
running the tests on the host.
Bug: 16705621
Bug: 17170200
Change-Id: Ia92c871b15f7e45fc174bb59bc95540fd00ae745
This way it's a lot harder for us to screw up (since we should always
be including <sys/cdefs.h> anyway).
Bug: 14659579
Change-Id: I23070fff3296b0d1c683bb5e3a6e214146327d53
<features.h> is supposed to take user-settable stuff like _GNU_SOURCE
and _BSD_SOURCE and turn them into __USE_GNU and __USE_BSD for use in
the C library headers. Instead, bionic used to unconditionally define
_BSD_SOURCE and _GNU_SOURCE, and then test _GNU_SOURCE in the header
files (which makes no sense whatsoever).
Bug: 14659579
Change-Id: Ice4cf21a364ea2e559071dc8329e995277d5b987
1. Add test for __attribute__((constructor/destructor))
and static constructor
2. Compile C++ testlibs with -std=gnu++11
Change-Id: I67f9308144a0c638a51f111fcba8e1933fe0ba41
Reduce randomization of the test by (1) replacing random() & 255
with hard-coded char and (2) by making State *Iteration function
visit every possible alignment combination instead of 10 random ones.
Change-Id: I0ff0b4ca817ba9fbbcce53e09b25eb10a1a853c2
ifuncs now work in i386 and x86_64 when called in the same library as
well as in a different library.
Bug:6657325
Change-Id: Ic0c48b1b0a76cb90f36c20c79f68294cc3fd44a1
During pthread_exit, the keys are cleaned. Unfortunately, a call to
free occurs after the cleanup and the memory for some of the keys
is recreated when using jemalloc. The solution is to do the key
cleanup twice.
Also, modify the pthread_detach__leak test to be less flaky
when run on a jemalloc system.
Bug: 16513133
Change-Id: Ic17e8344bdc1ba053c4f5b6d827a4c19c57860c1
During pthread_exit, the keys are cleaned. Unfortunately, a call to
free occurs after the cleanup and the memory for some of the keys
is recreated when using jemalloc. The solution is to do the key
cleanup twice.
Also, modify the pthread_detach__leak test to be less flaky
when run on a jemalloc system.
Bug: 16513133
(cherry picked from commit 18d93f2793fad393b6aa6eae6afe1054958339d5)
Change-Id: Idb32e7f9b09e2c088d256ed9eb881df80c81ff8e
Previously this was hard coded to 4. This is only the case for UTF-8
locales.
As a side effect, this properly reports C.UTF-8 as the default locale
instead of C.
Change-Id: I7c73cc8fe6ffac61d211cd5f75287e36de06f4fc
(cherry picked from commit 1aec7c1a35b2d03038b194967d5ebdc8e2c24b80)
A mistake I made while cleaning this up the first time through.
mbstrtowcs(3) sets the src param to null if it finishes the string.
Change-Id: I6263646e25d9537043b7025fd1dd6ae195f365e2
(cherry picked from commit b6cc8e00cd562bd0f81fe44a6bc646540a862f32)
The memchr implementation for 64 bit fails if these conditions occur:
- The buffer is 32 byte aligned.
- The buffer contains the character in the first byte.
- The count sent in is zero.
The function should return NULL, but it's not.
Bug: 16676625
(cherry picked from commit e03e1eac0b7682884b6628df1305d34299680cb4)
Change-Id: Ie4cca2c445127a0936ee2b96651a8e7204fbaffd
A mistake I made while cleaning this up the first time through.
mbstrtowcs(3) sets the src param to null if it finishes the string.
Change-Id: I6263646e25d9537043b7025fd1dd6ae195f365e2
Previously this was hard coded to 4. This is only the case for UTF-8
locales.
As a side effect, this properly reports C.UTF-8 as the default locale
instead of C.
Change-Id: I7c73cc8fe6ffac61d211cd5f75287e36de06f4fc
The memchr implementation for 64 bit fails if these conditions occur:
- The buffer is 32 byte aligned.
- The buffer contains the character in the first byte.
- The count sent in is zero.
The function should return NULL, but it's not.
Bug: 16676625
Change-Id: Iab33cc7a8b79920350c72f054dff0e0a3cde69ce
dlsym(3) with handle != RTLD_DEFAULT|RTLD_NEXT performs
breadth first search through the dependency tree.
Bug: 16653281
Change-Id: I017a6975d1a62abb0218a7eb59ae4deba458e324
Also clean up the implementation of all the pty functions, add tests,
and fix the stub implementations of ttyname(3) and ttyname_r(3).
Bug: https://code.google.com/p/android/issues/detail?id=58888
Change-Id: I0fb36438cd1abf8d4e87c29415f03db9ba13c3c2
The len parameter is a _maximum_ length. The previous code was treating
it as an exact length, causing the following typical call to fail:
mbsrtowcs(out, &in, sizeof(out), state); // sizeof(out) > strlen(in)
Change-Id: I48e474fd54ea5f122bc168a4d74bfe08704f28cc
(cherry picked from commit 6b55ba54eff4657cffe053b71e1c9cce2944a8a9)
Also clean up the implementation of all the pty functions, add tests,
and fix the stub implementations of ttyname(3) and ttyname_r(3).
Bug: https://code.google.com/p/android/issues/detail?id=58888
(cherry picked from commit 4916706cfe590eb06c9b5bd4bd402ce056034d51)
Change-Id: I5cb7a1c17b156456e4c4818e65f256eb8d045424
This doesn't require us to change any of the syscall implementations
because (a) the LP32 ones have sizeof(int) == sizeof(long) anyway,
which is how we never noticed this bug before and (b) the LP64 ones
all use a 64-bit register for the result (and for the syscall number
too).
Bug: https://code.google.com/p/android/issues/detail?id=73952
Bug: 16568314
(cherry picked from commit 21972b61ec0572395c5684eebc6cc7b3a4c9e3be)
Change-Id: Ifbc424be29e5650ec72a24df25dd35f24fdd5b3c
It seemed like a clever trick to use the internal log message formatting
code in syslog(3), but on reflection that means you can't (for example)
format floating point numbers. This patch switches us over to using good
old vsnprintf(3), even though that requires us to jump through a few hoops.
There's no obvious way to unit test this, so I wrote a little program and
ran that.
Bug: 14292866
Change-Id: I9c83500ba9cbb209b6f496067a91bf69434eeef5
dlsym(3) with handle != RTLD_DEFAULT|RTLD_NEXT performs
breadth first search through the dependency tree.
Bug: 16653281
(cherry picked from commit aa0f2bdbc22d4b7aec5d3f8f5f01eaeaa13414c2)
Change-Id: I0ba8c2034ab341f8a279cdb4e2e7e47f1aef7897
On 32-bit MIPS, 64-bit atomic ops are achieved through locks.
So allow the test to fail for atomic_intmax_t on 32-bit MIPS.
(cherry picked from commit f1837377d215a6eda294b6ac7552b226deee91ce)
Change-Id: I973d999c31c9ab89b5a7b709beff6486b93408f2
I've also added insque(3) and remque(3) (from NetBSD because the OpenBSD
ones are currently broken for non-circular lists).
I've not added the three hash table functions that should be in this header
because they operate on a single global hash table and thus aren't likely
to be useful.
Bug: https://code.google.com/p/android/issues/detail?id=73719
(cherry picked from commit 3e424d0a241f8ae5194514dabc4ad899f5a5416d)
Change-Id: I5882a6b48c80fea8ac6b9c27e7b9de10b202b4ff
PR_GET_DUMPABLE is used by an application to indicate whether or
not core dumps / PTRACE_ATTACH should work.
Security sensitive applications often set PR_SET_DUMPABLE to 0 to
disable core dumps, to avoid leaking sensitive memory to persistent
storage. Similarly, they also set PR_SET_DUMPABLE to zero to prevent
PTRACE_ATTACH from working, again to avoid leaking the contents
of sensitive memory.
Honor PR_GET_DUMPABLE when connecting to debuggerd. If an application
has said it doesn't want its memory dumped, then we shouldn't
ask debuggerd to dump memory on its behalf.
FORTIFY_SOURCE tests: Modify the fortify_source tests to set
PR_SET_DUMPABLE=0. This reduces the total runtime of
/data/nativetest/bionic-unit-tests/bionic-unit-tests32 from approx
53 seconds to 25 seconds. There's no need to connect to debuggerd
when running these tests.
Bug: 16513137
(cherry picked from commit be0e43b77676338fd5e6a82c9cc2b6302d579de2)
Change-Id: I6e1a9bce564e94fc19893d639b15f38c549cabfa
On 32-bit MIPS, 64-bit atomic ops are achieved through locks.
So allow the test to fail for atomic_intmax_t on 32-bit MIPS.
Change-Id: I78e7807e50f899a0fea0d5b388d9ebb53228aaa0
I've also added insque(3) and remque(3) (from NetBSD because the OpenBSD
ones are currently broken for non-circular lists).
I've not added the three hash table functions that should be in this header
because they operate on a single global hash table and thus aren't likely
to be useful.
Bug: https://code.google.com/p/android/issues/detail?id=73719
Change-Id: I97397a7b921e2e860fd9c8032cafd9097380498a
This doesn't require us to change any of the syscall implementations
because (a) the LP32 ones have sizeof(int) == sizeof(long) anyway,
which is how we never noticed this bug before and (b) the LP64 ones
all use a 64-bit register for the result (and for the syscall number
too).
Bug: https://code.google.com/p/android/issues/detail?id=73952
Change-Id: I9866c3579a7a94de27bfbe80ad7a822c3183c7fb
It seemed like a clever trick to use the internal log message formatting
code in syslog(3), but on reflection that means you can't (for example)
format floating point numbers. This patch switches us over to using good
old vsnprintf(3), even though that requires us to jump through a few hoops.
There's no obvious way to unit test this, so I wrote a little program and
ran that.
(cherry-pick of b1b60c30bf321c0fc02264b953b5c16c49d34457.)
Bug: 14292866
Change-Id: I9c83500ba9cbb209b6f496067a91bf69434eeef5
PR_GET_DUMPABLE is used by an application to indicate whether or
not core dumps / PTRACE_ATTACH should work.
Security sensitive applications often set PR_SET_DUMPABLE to 0 to
disable core dumps, to avoid leaking sensitive memory to persistent
storage. Similarly, they also set PR_SET_DUMPABLE to zero to prevent
PTRACE_ATTACH from working, again to avoid leaking the contents
of sensitive memory.
Honor PR_GET_DUMPABLE when connecting to debuggerd. If an application
has said it doesn't want its memory dumped, then we shouldn't
ask debuggerd to dump memory on its behalf.
FORTIFY_SOURCE tests: Modify the fortify_source tests to set
PR_SET_DUMPABLE=0. This reduces the total runtime of
/data/nativetest/bionic-unit-tests/bionic-unit-tests32 from approx
53 seconds to 25 seconds. There's no need to connect to debuggerd
when running these tests.
Bug: 16513137
Change-Id: Idc7857b089f3545758f4d9b436b783d580fb653f
Since we don't have syslogd on Android and you can't run one on a non-rooted
device, it's more useful if syslog output just goes to the regular Android
logging system.
Bug: 14292866
(cherry picked from commit 3ad8ecb64e9dd5614169232b84a93eb3b8aa32d7)
Change-Id: I3038855ca4f22532bf6d2c45d3f8028b866975f9
