This also adds _2-variants for these functions, for extra glorious
checking
Bug: 131861088
Test: mma
Change-Id: I80475ff4bb220c0c47894e9532426f53412f176f
Historical research (see bug) suggests that these functions were all in
22. The map file believed this with one (presumably typoed) exception,
but the header file didn't match the map file. It looks like the map was
correct (modulo the one typo), so fix up all the disagreement.
Bug: http://b/113618851
Test: treehugger
Change-Id: Ia579f4e6163206abfac79aa54dc98c792f00ee86
Add the malloc symbols used by libmemunreachable to the VNDK, and
make libc_malloc_debug_backtrace vendor_available.
Bug: 132302484
Test: m checkbuild
Change-Id: Ide555195afa084c13eaeaf0eab6ff90787b5f2d0
Added get_malloc_leak_info and free_malloc_leak_info for arm 32 bit
only so that the kindle app will continue to run.
Bug: 132175052
Test: Ran kindle app, read pdf file. Verified libKindleReaderJNI.so
Test: is loaded in memory properly.
Change-Id: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
Merged-In: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
(cherry picked from commit 235f35a266)
FreeBSD, glibc, and musl have all implemented C11 threads at this
point. POSIX is looking at how to align with it. Probably time to jump
on the bandwagon ourselves...
Implemented in the same style as <termios.h> so we can provide this
functionality even on older API levels. This does mean that this is
strictly more expensive than calling pthread functions directly.
Although this isn't in POSIX yet, assume that it's going to be basically
the same as C11 and add the header test anyway. We should revisit this
when POSIX actually adds <threads.h>.
Test: new tests
Change-Id: I8602d67ce71ca7f8ed1529daa0a8ea1feb083dd6
Bug: 130028357
Test: malloc_hooks unit tests.
Test: Enable backtrace for mediaserver, run dumpsys media.player -m
Test: Enable backtrace for calendar, run am dumpheap -n <PID> <FILE>
Change-Id: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
Merged-In: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
(cherry picked from commit 3aadc5e80a)
Remove this global variable and change the setting of it to non-zero
to a call to android_mallopt.
In addition, change the initialize function to use pass a bool* instead of
int*.
Bug: 130028357
Test: Ran malloc_debug/malloc_hooks/perfetto tests.
Change-Id: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
Merged-In: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
(cherry picked from commit 5225b342f0)
Introduce an M_SET_ALLOCATION_LIMIT enumerator for android_mallopt(),
which can be used to set an upper bound on the total size of all
allocations made using the memory allocation APIs.
This is useful for programs such as audioextractor and mediaserver
which need to set such a limit as a security mitigation. Currently
these programs are using setrlimit(RLIMIT_AS) which isn't exactly
what these programs want to control. RLIMIT_AS is also problematic
under sanitizers which allocate large amounts of address space as
shadow memory, and is especially problematic under shadow call stack,
which requires 16MB of address space per thread.
Add new unit tests for bionic.
Add new unit tests for malloc debug that verify that when the limit
is enabled, malloc debug still functions for nearly every allocation
function.
Bug: 118642754
Test: Ran bionic-unit-tests/bionic-unit-tests-static.
Test: Ran malloc debug tests and perfetto integration tests.
Change-Id: I735403c4d2c87f00fb2cdef81d00af0af446b2bb
After switching libm from libgcc to libcrt.builtins, some of the symbols
are no longer getting included in libm, causing the compiler to complain
about missing symbols from the version script. Explicitly export them in
libc (since libm depends on libc).
Bug: 122993571
Test: m checkbuild
Test: bionic-unit-tests
Change-Id: Ie91765874d20df605f557b1a8c4236619553c549
With the switch to libcrt.builtins, some symbols no longer becomes
exported. Add dummy references to them to force them to be exported.
This is to maintain backwards binary compatibility with ancient Android
versions.
x86 and x86_64 crashes with libcrt, keep using libgcc for now.
Test: bionic-unit-tests
Bug: 29275768
Bug: 122993569
Change-Id: Ieab5af354e3924af4a03d888b28c6e75090cb613
Initialize a thread's DTV to an empty zeroed DTV. Allocate the DTV and
any ELF module's TLS segment on-demand in __tls_get_addr. Use a generation
counter, incremented in the linker, to signal when threads should
update/reallocate their DTV objects.
A generation count of 0 always indicates the constant zero DTV.
Once a DTV is allocated, it isn't freed until the thread exits, because
a signal handler could interrupt the fast path of __tls_get_addr between
accessing the DTV slot and reading a field of the DTV. Bionic keeps a
linked list of DTV objects so it can free them at thread-exit.
Dynamic TLS memory is allocated using a BionicAllocator instance in
libc_shared_globals. For async-signal safety, access to the
linker/libc-shared state is protected by first blocking signals, then by
acquiring the reader-writer lock, TlsModules::rwlock. A write lock is
needed to allocate or free memory.
In pthread_exit, unconditionally block signals before freeing dynamic
TLS memory or freeing the shadow call stack.
ndk_cruft.cpp: Avoid including pthread_internal.h inside an extern "C".
(The header now includes a C++ template that doesn't compile inside
extern "C".)
Bug: http://b/78026329
Bug: http://b/123094171
Test: bionic unit tests
Change-Id: I3c9b12921c9e68b33dcc1d1dd276bff364eff5d7
On user builds, heapprofd should only be allowed to profile apps that
are either debuggable, or profileable (according to the manifest). This
change exposes extra zygote-specific knowledge to bionic, and makes the
dedicated signal handler check for the special case of being in a zygote child.
With this & the corresponding framework change, we should now be
handling the 4 combinations of:
{java, native} x {profile_at_runtime, profile_at_startup}.
See internal go/heapprofd-java-trigger for further context.
Test: on-device unit tests (shared & static) on blueline-userdebug.
Test: flashed blueline-userdebug, confirmed that java profiling activates from startup and at runtime.
Bug: 120409382
Change-Id: Ic251afeca4324dc650ac1d4f46976b526eae692a
(cherry picked from commit 998792e2b6)
Merged-In: Ic251afeca4324dc650ac1d4f46976b526eae692a
This reverts commit 220f51e566.
The internal modules that were using extra symbols are all fixed.
Bug: 120266448
Test: m ndk_translation_all in cf_x86_phone
Change-Id: I561b16de1c320d2624e7cf8e6211e0c70edc823d
By default, Clang uses this arm32 function to read the thread pointer,
either for ELF TLS or via __builtin_thread_pointer(). It's probably better
to inline the cp15 access using -mtp=cp15, but that's not the default yet.
See https://reviews.llvm.org/D34878?id=114573.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I93b8926075f0b2cea8df9ef518d54f2820a8ff5b
Following additional symbols are temporarily exposed from the runtime APEX
to satisfy the dependencies from other non-AOSP modules. This will be
reverted when the modules are built with the boostrap bionic libraries.
Bug: 120266448
Test: m
Change-Id: I39ac40a40545723ea2aeb185b9cd293d511f802f
Bionic libs are part of the runtime APEX (com.android.runtime). In order
to be able to update the runtime APEX independetly from the platform, we
have to prevent things outside of the APEX from using bionic symbols
that are not guaranteed to be stable. Otherwise, platform could break
when a symbol is removed from the libs via the APEX update.
To achive this goal, this change adds stubs variant to the bionic libs.
With this, things outside of the runtime APEX (i.e. other APEXes and the
platform) are built with the stubs variants that provide only the
symbols that are guaranteed to be stable.
The set of symbols are basically the same as the symbols available to
NDK clients. However, there are a few additional symbols that are not
available for NDK but should be made available for platform components.
They are marked with "# apex" tag. Symbols with that tag are not exposed
to apps (via NDK stubs) or vendors (via LLNDK stubs).
Note that the stubs is a build-time only artifact. It is used just to
break the build when private symbols are used outside of the runtime
APEX. At runtime, the real library in the APEX is used.
Bug: 120266448
Test: m
Test: m bionic-unit-tests
Change-Id: I7b8d75830c81d7d7d54e2fca21a85b3417531b47
Originally a BSD extension, now in glibc too. We've used it internally
for a while.
(cherry-pick of e4b13f7e3ca68edfcc5faedc5e7d4e13c4e8edb9.)
Bug: http://b/112163459
Test: ran tests
Change-Id: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Merged-In: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Make it easier to write tests in users of fdsan by exposing functions
to allow users to get and interpret the tags.
Test: bionic_unit_tests
Change-Id: Iafa9bcaeb5e4db230f3dfec6f483274f34602694
Let the debuggerd handler get the address of the fdsan table so that
crash_dump can parse it and print it out in tombstones.
Test: debuggerd `pidof adbd`
Change-Id: I2297200cae52d0ff24479dba55d1ab4938583501
Add two functions to allow objects that own a file descriptor to
enforce that only they can close their file descriptor.
Use them in FILE* and DIR*.
Bug: http://b/110100358
Test: bionic_unit_tests
Test: aosp/master boots without errors
Test: treehugger
Change-Id: Iecd6e8b26c62217271e0822dc3d2d7888b091a45
I don't think this will help the original submitter, because <resolv.h>
is mostly useless on Android. One day we might have a deprecation and
removal policy for the NDK, but until then we should probably maintain
this header.
Bug: https://github.com/android-ndk/ndk/issues/739
Test: ran tests
Change-Id: I2db859abfdebc3824c997462fa6133d5b355a8dd
Bump the version from v1.1 to v1.2 and add a build fingerprint line.
Update the heap dump documentation to match the new format and reflect
what made it in P and what made it in Q.
Update the unit tests for this change.
Add -O0 to unit test code to make it easier to debug.
Add an external function that can be used by the framework code
so that there is only one way to dump the heap.
Bug: 110095681
Test: Ran unit tests.
Test: Did a dump of a real process and verified fingerprint.
Test: Did a dump of a process without malloc debug enabled.
Change-Id: I769a476cbeaf4c85c5d75bd6d6385f0e3add948c
Merged-In: I769a476cbeaf4c85c5d75bd6d6385f0e3add948c
(cherry picked from commit c84a2a2601)
Apparently this didn't make it to all android-16 devices. As far as
we know it did make it for all android-17 devices.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/647
Change-Id: I2f07cfb1254e2a203c1c10b91b0be46bf37ea853
I've deliberately not bothered with the GCC implementation because we'll
have removed GCC from the NDK before anyone gets to use this.
Bug: http://b/72493232
Test: ran tests
Change-Id: Icfc2a3b214739ab53aa41bacacc11b5c67498fb4
As a follow up to Ibba98f5d88be1c306d14e9b9366302ecbef6d534, where we
added a work around to convert the CLOCK_REALTIME timeouts to
CLOCK_MONOTONIC for pthread and semaphore timed wait functions, we're
introducing a set of _monotonic_np versions of each of these functions
that wait on CLOCK_MONOTONIC directly.
The primary motivation here is that while the above work around helps
for 3rd party code, it creates a dilemma when implementing new code
that would use these functions: either one implements code with these
functions knowing there is a race condition possible or one avoids
these functions and reinvent their own waiting/signaling mechanisms.
Neither are satisfactory, so we create a third option to use these
Android specific _monotonic_np functions that completely remove the
race condition while keeping the rest of the interface.
Specifically this adds the below functions:
pthread_mutex_timedlock_monotonic_np()
pthread_cond_timedwait_monotonic_np()
pthread_rwlock_timedrdlock_monotonic_np()
pthread_rwlock_timedwrlock_monotonic_np()
sem_timedwait_monotonic_np()
Note that pthread_cond_timedwait_monotonic_np() previously existed and
was removed since it's possible to initialize a condition variable to
use CLOCK_MONOTONIC. It is added back for a mix of reasons,
1) Symmetry with the rest of the functions we're adding
2) libc++ cannot easily take advantage of the new initializer, but
will be able to use this function in order to wait on
std::steady_clock
3) Frankly, it's a better API to specify the clock in the waiter function
than to specify the clock when the condition variable is
initialized.
Bug: 73951740
Test: new unit tests
Change-Id: I23aa5c204e36a194237d41e064c5c8ccaa4204e3
Trivial, obvious counterpart to the standard ferror(3) and clearerr(3),
and lets us build bison out of the box.
Bug: http://b/64273806
Test: ran tests
Change-Id: I20affabddb71210051165c41e86adfe5ae04f77f
Use the malloc debug framework to implement the malloc debug hooks
since it can introduce a performance issue.
Also, modify the bionic/tests/utils.h slightly to dump an error message
when the exe failed.
Bug: 30561479
Test: Ran malloc hook unit tests.
Test: Ran malloc debug unit tests.
Test: Enabled malloc hooks and ran bionic unit tests and verified no
Test: unexpected failures.
Test: Enabled malloc debug and malloc hooks and verified malloc debug wins.
Test: Enabled malloc debug using env, property, and property with name
Test: still works.
Change-Id: Ib50046a0493c5c2050cf831befb812310bdcc249
(cherry picked from commit d6a1dc2379)
This doesn't address `struct sigaction` and `sigaction`. That will
come later.
Bug: http://b/72493232
Test: ran tests
Change-Id: I4134346757ce3a4dac6feae413361cec16223386
Bug: http://b/29177606
Test: run bionic-unit-tests on walleye.
Test: run bionic-unit-tests-glibc on host.
Change-Id: Iac349284aa73515f384e7509445f87434757f59e
Also simplify trivial one-liners like perror/puts/fputs, and clean up
fread/fwrite slightly.
Fix perror to match POSIX.
Add basic perror and *_unlocked tests.
Bug: N/A
Test: ran tests
Change-Id: I63f83c8e0c15c3c4096509d17421ac331b6fc23d
Historically, Android defaulted to EXPLICIT but with a special case
because SCHED_NORMAL/priority 0 was awkward. Because the code couldn't
actually tell whether SCHED_NORMAL/priority 0 was a genuine attempt to
explicitly set those attributes (because the parent thread is SCHED_FIFO,
say) or just because the pthread_attr_t was left at its defaults.
Now we support INHERIT, we could call sched_getscheduler to see whether
we actually need to call sched_setscheduler, but since the major cost
is the fixed syscall overhead, we may as well just conservatively
call sched_setscheduler and let the kernel decide whether it's a
no-op. (Especially because we'd then have to add both sched_getscheduler
and sched_setscheduler to any seccomp filter.)
Platform code (or app code that only needs to support >= P) can actually
add a call to pthread_attr_setinheritsched to say that they just want
to inherit (if they know that none of their threads actually mess with
scheduler attributes at all), which will save them a sched_setscheduler
call except in the doubly-special case of SCHED_RESET_ON_FORK (which we
do handle).
An alternative would be "make pthread_attr_setschedparams and
pthread_attr_setschedprio set EXPLICIT and change the platform default
to INHERIT", but even though I can only think of weird pathological
examples where anyone would notice that change, that behavior -- of
pthread_attr_setschedparams/pthread_attr_setschedprio overriding an
earlier call to pthread_attr_setinheritsched -- isn't allowed by POSIX
(whereas defaulting to EXPLICIT is).
If we have a lot of trouble with this change in the app compatibility
testing phase, though, we'll want to reconsider this decision!
-*-
This change also removes a comment about setting the scheduler attributes
in main_thread because we'd have to actually keep them up to date,
and it's not clear that doing so would be worth the trouble.
Also make async_safe_format_log preserve errno so we don't have to be
so careful around it.
Bug: http://b/67471710
Test: ran tests
Change-Id: Idd026c4ce78a536656adcb57aa2e7b2c616eeddf
I'm skeptical about the usefulness of this, but it's in POSIX, it's
in glibc (but not iOS), and it is used in some internal source (test
runners and container code).
Bug: N/A
Test: ran tests
Change-Id: I92c5398f2a679b21a33fba92bc8e67e3ae2eb76f
Surprisingly to me, there are actual uses of `swab` in the codebases
I have available to search, including one with a #ifndef __ANDROID__
around it.
Bug: N/A
Test: ran tests
Change-Id: Ic91b78ae22bb65c346cb46dd38916f48d979abe0
