The tests are using /data/data which is not accessible to a non-root
user. Change this to /data/local/tmp which is accessible to all users.
Bug: 8291716
Change-Id: I66476bbbaf5d1dc0c103863abf9219405f06a85b
clock_gettime was returning EINVAL for the values
produced by pthread_getcpuclockid.
Bug: 10346183
(cherry picked from commit 9b06cc3c1b)
Change-Id: Ib81a7024c218a4502f256c3002b9030e2aaa278d
I've mailed the tz list about this, and will switch to whatever upstream
fix comes along as soon as it's available.
Bug: 10310929
(cherry picked from commit 7843d44a59)
Change-Id: I205e2440703444c50cecd91d3458d33613ddbc59
I've mailed the tz list about this, and will switch to whatever upstream
fix comes along as soon as it's available.
Bug: 10310929
Change-Id: I36bf3fcf11f5ac9b88137597bac3487a7bb81b0f
clock_gettime was returning EINVAL for the values
produced by pthread_getcpuclockid.
Bug: 10346183
Change-Id: Iabe643d7d46110bb311a0367aa0fc737f653208e
The properties tests creates a temporary directory in /data/nativetest,
but this directory might not exist in all circumstances.
Change this to create the temporary directory in /data/local/tmp.
Change-Id: I812d3e24fcd084c5d74055c9faa95b1656f255bc
__memcmp16 was missing in x86. Also added C-version for backward
compatibility. Added bionic test for __memcmp16 and for wmemcmp.
Change-Id: I33718441e7ee343cdb021d91dbeaf9ce2d4d7eb4
Signed-off-by: Alexander Ivchenko <alexander.ivchenko@intel.com>
pthread_getattr_np was reporting the values supplied to us, not the values we
actually used, which is kinda the whole point of pthread_getattr_np.
pthread_attr_setguardsize and pthread_attr_setstacksize were reporting EINVAL
for any size that wasn't a multiple of the system page size. This is
unnecessary. We can just round like POSIX suggests and glibc already does.
Also improve the error reporting for pthread_create failures.
Change-Id: I7ebc518628a8a1161ec72e111def911d500bba71
Our intptr_t and uintptr_t aren't "long". Add a compilation test so we remember
to fix this to cope with 32- and 64-bit later.
Bug: http://code.google.com/p/android/issues/detail?id=57218
Change-Id: I2f816d339edb4f7d57e4418b818fb4c602093f38
Get rid of a lot of the duplication in the various FORTIFY_SOURCE
tests. Instead, we build 4 separate static libraries, with
4 different compile time options, and link them into the final test
binary.
Change-Id: Idb0b7cccc8dd837adb037bf4ddfe8942ae138230
Enable FORTIFY_SOURCE protections under clang for the following
functions:
* vsprintf
* vsnprintf
and add unittests.
Change-Id: I90f8a27f7b202c78b5dd8ebf53050bf9e33496f7
d329697 is too complicated. Change the multiple property pages back to
a single 128K property area that's mapped in entirely at initialization
(the memory will not get allocated until the pages are touched).
d329697 has other changes useful for testing (moving property area
initialization inside bionic and adding __system_property_set_filename)
so undo the change manually rather than with git revert.
Change-Id: Icd137669a4f8bc248e9dd2c1e8cc54e9193c9a6d
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Deliberately put items several levels deep in the trie hierarchy to test
the trie traversal
Change-Id: I995a1cdd3b5e74162fb5d25bc0f65140bdf2f719
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Kernel provides virtual DSO for stack unwinding/exception handlind info for
signal usage case. Stack unwinding routines use 'dl_iterate_phdr' function
for additional DWARF info gathering from DSOs. Patch enables virtual DSO
enumeration via dl_iterate_phdr function.
Signed-off-by: Sergey Melnikov <sergey.melnikov@intel.com>
Change-Id: Ic2882b28f40b456a088bc1e63c50cbfda7e4a102
d329697 is too complicated. Change the multiple property pages back to
a single 128K property area that's mapped in entirely at initialization
(the memory will not get allocated until the pages are touched).
d329697 has other changes useful for testing (moving property area
initialization inside bionic and adding __system_property_set_filename)
so undo the change manually rather than with git revert.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
(cherry picked from commit 5f05348c18)
Change-Id: I690704552afc07a4dd410277893ca9c40bc13e5f
The property area is initially one 4K region, automatically expanding as
needed up to 64 regions.
To avoid duplicating code, __system_property_area_init() now allocates
and initializes the first region (previously it was allocated in init's
init_property_area() and initialized in bionic). For testing purposes,
__system_property_set_filename() may be used to override the file used
to map in regions.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
(cherry picked from commit d32969701b)
Change-Id: I038d451fe8849b0c4863663eec6f57f6521bf4a7
d329697 is too complicated. Change the multiple property pages back to
a single 128K property area that's mapped in entirely at initialization
(the memory will not get allocated until the pages are touched).
d329697 has other changes useful for testing (moving property area
initialization inside bionic and adding __system_property_set_filename)
so undo the change manually rather than with git revert.
Change-Id: I0ecb27843404f93af5489f15bfe657d65175e4f0
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Deliberately put items several levels deep in the trie hierarchy to test
the trie traversal
Change-Id: Id3cbd2e7d3500216b1ac8025eac70c0939622903
Signed-off-by: Greg Hackmann <ghackmann@google.com>
The property area is initially one 4K region, automatically expanding as
needed up to 64 regions.
To avoid duplicating code, __system_property_area_init() now allocates
and initializes the first region (previously it was allocated in init's
init_property_area() and initialized in bionic). For testing purposes,
__system_property_set_filename() may be used to override the file used
to map in regions.
Change-Id: Ibe00ef52464bfa590953c4699a6d98383b0142b1
Signed-off-by: Greg Hackmann <ghackmann@google.com>
find_nth() will be inefficient on a trie. Since find_nth() is only used
internally and only for enumerating properties, we can add a foreach()
function to do this directly.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
(cherry picked from commit 577418403d)
Change-Id: Iaca97d1182ce2c28863ba85241cbb5cf6185eb2f
The properties benchmarks were reading n properties from a property
area with n properties in it, which was making it hard to compare
the time between runs of different sizes. Change the benchmark
to read a random property per iteration so the numbers between
runs are comparable.
Change-Id: Ib1648ce0948d9038fce76d209608427376cfb8da
In 829c089f83, we disabled all
FORTIFY_SOURCE support when compiling under clang. At the time,
we didn't have proper test cases, and couldn't easily create targeted
clang tests.
This change re-enables FORTIFY_SOURCE support under clang for a
limited set of functions, where we have explicit unittests available.
The functions are:
* memcpy
* memmove
* strcpy
* strncpy
* strcat
* strncat
* memset
* strlen (with modifications)
* strchr (with modifications)
* strrchr (with modifications)
It may be possible, in the future, to enable other functions. However,
I need to write unittests first.
For strlen, strchr, and strrchr, clang unconditionally calls the
fortified version of the relevant function. If it doesn't know the
size of the buffer it's dealing with, it passes in ((size_t) -1),
which is the largest possible size_t.
I added two new clang specific unittest files, primarily copied
from fortify?_test.cpp.
I've also rebuild the entire system with these changes, and didn't
observe any obvious problems.
Change-Id: If12a15089bb0ffe93824b485290d05b14355fcaa
Removed 'join_count' from pthread_internal_t and switched to using the flag
PTHREAD_ATTR_FLAG_JOINED to indicate if a thread is being joined. Combined with
a switch to a while loop in pthread_join, this fixes spurious wake-ups but
prevents a thread from being joined multiple times. This is fine for
two reasons:
1) The pthread_join specification allows for undefined behavior when multiple
threads try to join a single thread.
2) There is no thread safe way to allow multiple threads to join a single
thread with the pthread interface. The second thread calling pthread_join
could be pre-empted until the thread is destroyed and its handle reused for
a different thread. Therefore multi-join is always an error.
Bug: https://code.google.com/p/android/issues/detail?id=52255
Change-Id: I8b6784d47620ffdcdbfb14524e7402e21d46c5f7
7e6ce1a3c5 fixed abort() to raise
SIGABRT rather than causing SIGSEGV. However, the unittests were
not updated.
Fix unittests.
Change-Id: I73db194127b9b9e9440358aa94273863765a736b
- Implemented chk_memalign.
- Fixed a few bugs in leak_memalign.
- Implemented {leak,fill,check,qemu}_malloc_usable_size.
- Make malloc_usable_size update at run time.
- Add malloc_test.cpp as a small set of tests for the
malloc debug routines.
- Fix the qemu routines since it's been broken since it moved to C++.
- Add support for the %u format to the out_vformat in libc_logging.cpp.
This is used by the emulator code.
Tested using the bionic-unit-tests with setprop libc.debug.malloc
set to 1, 5, and 10.
I tested as much as possible on the emulator, but tracing doesn't appear
to be working properly.
Bug: 6143477
Merge change from internal master.
(cherry-picked from commit 3d594c2580)
Change-Id: I4ae00fffba82315a8c283f35893fd554460722fb
__strcat_chk and __strncat_chk are slightly inefficient,
because they end up traversing over the same memory region
two times.
This change optimizes __strcat_chk / __strncat_chk so they
only access the memory once. Although I haven't benchmarked these
changes, it should improve the performance of these functions.
__strlen_chk - expose this function, even if -D_FORTIFY_SOURCE
isn't defined. This is needed to compile libc itself without
-D_FORTIFY_SOURCE.
Change-Id: Id2c70dff55a276b47c59db27a03734d659f84b74
Add support for fortify source level 2 to strncpy.
This will enable detection of more areas where strncpy
is used inappropriately. For example, this would have detected
bug 8727221.
Move the fortify_source tests out of string_test.cpp, and
put it into fortify1_test.cpp.
Create a new fortify2_test.cpp file, which copies all
the tests in fortify1_test.cpp, and adds fortify_source level
2 specific tests.
Change-Id: Ica0fba531cc7d0609e4f23b8176739b13f7f7a83
- eventfd.cpp and eventfd.s will output to the same file when building libc.a
out/target/product/*/obj/STATIC_LIBRARIES/libc_intermediates/WHOLE/libc_common_objs/eventfd.o
- And then `eventfd` will undefined when statically linked to libc.
Also add a unit test.
Change-Id: Ib310ade3256712ca617a90539e8eb07459c98505
We only need one logging API, and I prefer the one that does no
allocation and is thus safe to use in any context.
Also use O_CLOEXEC when opening the /dev/log files.
Move everything logging-related into one header file.
Change-Id: Ic1e3ea8e9b910dc29df351bff6c0aa4db26fbb58
In the old code, the index was a file to itself, so it made sense to
read until you hit the end of the file. In the new code, the index is
followed by hundreds of KiB of data, so we need to just search the
index.
Bug: 8368791
Change-Id: Icf5f8b5516cf3a93679fa849c9f6cd1cb100e0f1
Normally, the C library implicitly caches your timezone by virtue
of the fact that the prehistoric API assumes a single timezone for
the entire process.
The unfortunate mktime_tz and localtime_tz extensions work around
this, but represent timezones as strings to their callers, so code
that makes heavy use of these needs a cache to be able to perform
acceptably until it can hopefully one day be rewritten to use
java.util.Calendar or icu4c.
Bug: 8270865
Change-Id: I92e3964e86dc33ceac925f819cc5e26ff4203f50
This gets us back to using vfork now our ARM vfork assembler stub is
fixed, and adds the missing thread safety for the 'pidlist'.
Bug: 5335385
Change-Id: Ib08bfa65b2cb9fa695717aae629ea14816bf988d
This is actually a slightly newer upstream version than the one I
originally pulled. Hopefully now it's in upstream-freebsd it will
be easier to track upstream, though I still need to sit down and
write the necessary scripts at some point.
Bug: 5110679
Change-Id: I87e563f0f95aa8e68b45578e2a8f448bbf827a33
We could special-case raise(3) in non-threaded programs, but the more
conservative course is to make pthread_kill(3) work in signal handlers
at the cost of a race shared by other C libraries.
Change-Id: I59fb23d03bdabf403435e731704b33acdf3e0234
after change 32822 was rejected, this is the more light-weight
version of the fix: libc/include/sys/types.h already - via
libc/kernel/common/linux/posix_types.h - includes a definition
of __kernel_ssize_t from libc/kernel/arch-*/asm/posix_types.h
which is architecture-specific, toolchain-agnostic and also
gets rid of the gcc -Wformat warning (which it issues correctly,
since this i̲s̲ indeed a bug in bionic)
Change-Id: Ie4503ab16628bc25815a836d07556f665e9795c7
imgtec pointed out that pthread_kill(3) was broken, but most of the
other functions that ought to return ESRCH for invalid/exited threads
were equally broken.
Change-Id: I96347f6195549aee0c72dc39063e6c5d06d2e01f
Fix the pthread_setname_np test to take into account that emulator kernels are
so old that they don't support setting the name of other threads.
The CLONE_DETACHED thread is obsolete since 2.5 kernels.
Rename kernel_id to tid.
Fix the signature of __pthread_clone.
Clean up the clone and pthread_setname_np implementations slightly.
Change-Id: I16c2ff8845b67530544bbda9aa6618058603066d
Now __stack_chk_fail calls abort(3) directly, we terminate with
SIGSEGV rather than SIGABRT. (Because of the workaround for the
debuggerd lossage in the abort(3) implementation, which was the
motivation for switching __stack_chk_fail over to abort(3).)
Also clarify the comment on the weird pthread death test, so it
doesn't get copied and pasted onto real death tests.
Change-Id: Ie832eaded61359c99e7a10db65e28f35e8f63eed
Some build servers are still out of date, so we're better off having
the known quanitity of the consistently out-of-date prebuilt host gcc.
Change-Id: Ib6308ae926ffa1ac5d95efbbf32052344c17a6b8
This reverts commit 6f94de3ca4
(Doesn't try to increase the number of TLS slots; that leads to
an inability to boot. Adds more tests.)
Change-Id: Ia7d25ba3995219ed6e686463dbba80c95cc831ca
MIPS and x86 appear to have been correct already.
(Also fix unit tests that ASSERT_EQ with errno so that the
arguments are in the retarded junit order.)
Bug: 3461078
Change-Id: I2418ea98927b56e15b4ba9cfec97f5e7094c6291
POSIX says pthread_create returns EAGAIN, not ENOMEM.
Also pull pthread_attr_t functions into their own file.
Also pull pthread_setname_np into its own file.
Also remove unnecessary #includes from pthread_key.cpp.
Also account for those pthread keys used internally by bionic,
so they don't count against the number of keys available to user
code. (They do with glibc, but glibc's limit is the much more
generous 1024.)
Also factor out the common errno-restoring idiom to reduce gotos.
Bug: 6702535
Change-Id: I555e66efffcf2c1b5a2873569e91489156efca42
This was originally motivated by noticing that we were setting the
wrong bits for the well-known tls entries. That was a harmless bug
because none of the well-known tls entries has a destructor, but
it's best not to leave land mines lying around.
Also add some missing POSIX constants, a new test, and fix
pthread_key_create's return value when we hit the limit.
Change-Id: Ife26ea2f4b40865308e8410ec803b20bcc3e0ed1
This brings us up to date with FreeBSD HEAD, fixes various bugs, unifies
the set of functions we support on ARM, MIPS, and x86, fixes "long double",
adds ISO C99 support, and adds basic unit tests.
It turns out that our "long double" functions have always been broken
for non-normal numbers. This patch fixes that by not using the upstream
implementations and just forwarding to the regular "double" implementation
instead (since "long double" on Android is just "double" anyway, which is
what BSD doesn't support).
All the tests pass on ARM, MIPS, and x86, plus glibc on x86-64.
Bug: 3169850
Bug: 8012787
Bug: https://code.google.com/p/android/issues/detail?id=6697
Change-Id: If0c343030959c24bfc50d4d21c9530052c581837
Don't do the fortify_source checks if we can determine, at
compile time, that the provided operation is safe.
This avoids silliness like calling fortify source on things like:
size_t len = strlen("asdf");
printf("%d\n", len);
and allows the compiler to optimize this code to:
printf("%d\n", 4);
Defer to gcc's builtin functions instead of pointing our code
to the libc implementation.
Change-Id: I5e1dcb61946461c4afaaaa983e39f07c7a0df0ae
The AT_RANDOM changes broke setuid / setgid executables
such as "ping". When the linker executes a setuid program,
it cleans the environment, removing any invalid environment
entries, and adding "NULL"s to the end of the environment
array for each removed variable. Later on, we try to determine
the location of the aux environment variable, and get tripped
up by these extra NULLs.
Reverting this patch will get setuid executables working again,
but getauxval() is still broken for setuid programs because of
this bug.
This reverts commit e3a49a8661.
Change-Id: I05c58a896b1fe32cfb5d95d43b096045cda0aa4a
Populate the stack canaries from the kernel supplied
AT_RANDOM value, which doesn't involve any system calls.
This is slightly faster (6 fewer syscalls) and avoids
unnecessarily reading /dev/urandom, which depletes entropy.
Bug: 7959813
Change-Id: If2b43100a2a9929666df3de56b6139fed969e0f1
e6e60065ff modified strerror_r to
treat errno as signed. However, the change to the test code
modified the "strerror" test, not the "strerror_r" test.
Make the same change for the strerror_r code.
Change-Id: Ia236a53df5745935e229a4446a74da8bed0cfd7b
Add a test to ensure that stack canaries are working
correctly. Since stack canaries aren't normally generated
on non-string functions, we have to enable stack-protector-all.
Add a test to ensure that an out of bounds strcpy generates
a runtime failure.
Change-Id: Id0d3e59fc4b9602da019e4d35c5c653e1a57fae4
The MIPS toolchain can't generate them because they're incompatible
with the MIPS ABI (which requires .dynsym match the GOT, while GNU-style
requires .dynsym to be sorted by hash code), so there's nothing to test.
Change-Id: I2220f452fe6fe595ec1312544cc741dd390a36a5
Spotted while running the tests on MIPS, where sigset_t is
actually large enough. The bits in sigset_t are used such that
signal 1 is represented by bit 0, so the range of signals is
actually [1, 8*sizeof(sigset_t)]; it seems clearer to reword
the code in terms of valid bit offsets [0, 8*sizeof(sigset_t)),
which leads to the usual bounds checking idiom.
Change-Id: Id899c288e15ff71c85dd2fd33c47f8e97aa1956f
raise() should use pthread_kill() in a pthreads environment.
For bionic this means it should always be used.
Change-Id: Ic679272b664d2b8a7068b628fb83a9f7395c441f
You could argue that this is hurting people smart enough to have manually
allocated a large-enough sigset_t, but those people are smart enough to
implement their own sigset functions too.
I wonder whether our least unpleasant way out of our self-inflicted 32-bit
cesspool is to have equivalents of _FILE_OFFSET_BITS such as _SIGSET_T_BITS,
so calling code could opt in? You'd have to be careful passing sigset_t
arguments between code compiled with different options.
Bug: 5828899
Change-Id: I0ae60ee8544835b069a2b20568f38ec142e0737b
Based on our open-source RE2 benchmarking code.
Includes benchmarks for a handful of <string.h> functions.
Change-Id: I30eb70d25dbf4ad5f2ca44976a8ce3b1ff7dad01
...and don't pass a non-heap pointer to free(3), either.
This patch replaces the "node** prev" with the clearer "node* prev"
style and fixes the null pointer dereference in the old code. That's
not sufficient to fix the reporter's bug, though. The pthread_internal_t*
for the main thread isn't heap-allocated --- __libc_init_tls causes a
pointer to a statically-allocated pthread_internal_t to be added to
the thread list.
Bug: http://code.google.com/p/android/issues/detail?id=37410
Change-Id: I112b7f22782fc789d58f9c783f7b323bda8fb8b7
Also ensure that dlopen(3) errors always include the name of the library we
failed to open.
Also fix a bug where we'd fall back to searching LD_LIBRARY_PATH and the
built-in paths for names that include slashes.
Bug: http://code.google.com/p/android/issues/detail?id=38479
Change-Id: Ib2c009ed083344a7a012749d58f8679db2f26c78
Most of these tests were in system/extras, but I've added more to cover other
cases explicitly mentioned by POSIX.
Change-Id: I5e8d77e4179028d77306935cceadbb505515dcde
pthread_no_op_detach_after_join test from bionic-unit-tests hangs
on x86 emulator. There is a race in the pthread_join, pthread_exit,
pthread_detach functions:
- pthread_join waits for the non-detached thread
- pthread_detach sets the detached flag on that thread
- the thread executes pthread_exit which just kills the now-detached
thread, without sending the join notification.
This patch improves the test so it fails on ARM too, and modifies
pthread_detach to behave more like glibc, not setting the detach state if
called on a thread that's already being joined (but not returning an error).
Change-Id: I87dc688221ce979ef5178753dd63d01ac0b108e6
Signed-off-by: Sergey Melnikov <sergey.melnikov@intel.com>
The declaration for alphasort() in <dirent.h> used the deprecated:
int alphasort(const void*, const void*);
while both Posix and GLibc use instead:
int alphasort(const struct dirent** a, const struct dirent** b);
See: http://pubs.opengroup.org/onlinepubs/9699919799/functions/alphasort.html
This patch does the following:
- Update the declaration to match Posix/GLibc
- Get rid of the upstream BSD code which isn't compatible with the new
signature.
- Implement a new trivial alphasort() with the right signature, and
ensure that it uses strcoll() instead of strcmp().
- Remove Bionic-specific #ifdef .. #else .. #endif block in
dirent_test.cpp which uses alphasort().
Even through strcoll() currently uses strcmp(), this does the right
thing in the case where we decide to update strcoll() to properly
implement locale-specific ordered comparison.
Change-Id: I4fd45604d8a940aaf2eb0ecd7d73e2f11c9bca96
Based on a pair of patches from Intel:
https://android-review.googlesource.com/#/c/43909/https://android-review.googlesource.com/#/c/44903/
For x86, this patch supports _both_ the global that ARM/MIPS use
and the per-thread TLS entry (%gs:20) that GCC uses by default. This
lets us support binaries built with any x86 toolchain (right now,
the NDK is emitting x86 code that uses the global).
I've also extended the original tests to cover ARM/MIPS too, and
be a little more thorough for x86.
Change-Id: I02f279a80c6b626aecad449771dec91df235ad01
I gave up trying to use the usual thread-local buffer idiom; calls to
calloc(3) and free(3) from any of the "dl" functions -- which live in
the dynamic linker -- end up resolving to the dynamic linker's stubs.
I tried to work around that, but was just making things more complicated.
This alternative costs us a well-known TLS slot (instead of the
dynamically-allocated TLS slot we'd have used otherwise, so no difference
there), plus an extra buffer inside every pthread_internal_t.
Bug: 5404023
Change-Id: Ie9614edd05b6d1eeaf7bf9172792d616c6361767
Add unit tests for dlerror(3) in various situations. I think We're at least
as good as glibc now.
Also factor out the ScopedPthreadMutexLock and use it here too.
Bug: http://code.google.com/p/android/issues/detail?id=38398
Change-Id: I040938b4366ab836e3df46d1d8055b92f4ea6ed8
Some userspace programs (e.g. perf) need getline.
Changes:
() add getdelim.c, getline.c from NetBSD (http://netbsd.org/) under the
NetBSD Foundation's (TNF) license ("2 clause" Berkeley-style license).
() add stub for reentrant.h header that is needed by getdelim.c
() add tests for getdelim(3) and getline(3).
() update NOTICE file.
Change-Id: I22ed82dd5904b9d7a3695535c04f502be3c27c5d
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
For applications that share resources across users such as
forward-locked applications, print out their group name correctly.
Change-Id: I06ee0b67e4325cfa415ffd7a03e301700399a66d
Also fix problem with multi-user IDs that the home directory was
returned as "/data" instead of "/" unlike all the other uids.
Change-Id: I914d22052e5a86552989f8969b85aadbc748c65d
Someone reported a bug if pthread_detach is called while a pthread_join is
already in progress, but I'm unable to reproduce it. Keep the tests I wrote,
though.
Change-Id: I3d71450bbbb5345f2cb213dc56310ec020d528cc
Several previous changes conspired to make a mess of the thread list
in static binaries. This was most obvious when trying to call
pthread_key_delete(3) on the main thread.
Bug: http://code.google.com/p/android/issues/detail?id=36893
Change-Id: I2a2f553114d8fb40533c481252b410c10656da2e
