malloc_common_dynamic.cpp is compiled into both libc.so and
libc_scudo.so. When compiled for libc_scudo.so, it doesn't try to load
libc_malloc_* libs from the runtime linker namespace. This is because,
unlike libc.so which is shared from the runtime APEX, libc_scudo.so is
copied to any APEX that it needs. Furthermore, libdl_android which
provides android_get_exported_namespace is not available for vendors. So
the vendor variant of libc_scudo.so can't anyway locate the runtime
namespace.
Bug: 130213757
Bug: 122566199
Test: `m libc_scudo libc_scudo` is successful
Test: inspect the built library to see if it has reference to
android_get_exported_namespace
Merged-In: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
Change-Id: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
(cherry picked from commit ff94a13d2d)
/system/lib/libc.so is a symlink to libc.so in the runtime APEX.
libc_malloc_* libraries are bundled with libc.so because they share
implementation details.
However, since libc.so is loaded in the default namespace where the
runtime APEX path (/apex/com.android.runtime/lib) is not accessible,
libc.so has been using libc_malloc_* from /system/lib. This is
wrong because libc.so (from the runtime APEX) and libc_malloc_* (from
the platform) may not be in-sync.
libc.so now uses android_dlopen_ext to load libc_malloc_* libraries
correctly from the "runtime" linker namespace.
Bug: 122566199
Test: bionic-unit-tests
Merged-In: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
Change-Id: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
(cherry picked from commit 4e46ac69c2)
Issue:
Process is crashed near the end (startup_handshake_lock.unlock()) in
pthread_create().
The newly created child thread passes this handshake_lock unexpectedly
=> its stack is unmapped & its associated pthread_internal_t data
structure can’t be accessed.
Analysis:
The created child thread should be blocked by startup_handshake_lock.lock()
and enter __futex_wait_ex()
But if the parent thread is in the middle of startup_handshake_lock.unlock():
void unlock() {
if (atomic_exchange_explicit(&state, Unlocked, memory_order_seq_cst) == LockedWithWaiter) { // => the state is modified to Unlocked
// (a) if the child thread is back to running and pass the while() check in Lock::lock()
// (b) the child thread executes its start_routine and then pthread_exit
// (c) the stack of the child thread (where its pthread_internal_t (so the startup_handshake_lock) is located) will be unmapped
__futex_wake_ex(&state, process_shared, 1); // => when the parent thread is back to running
// the “state” & “process_shared” of startup_handshake_lock can’t be accessed (unmapped)
// so the process will be crashed
}
}
Bug: 129744706
Test: Monkey
Change-Id: I55175e8c7ebc2b3b52de8a5602def0667076b974
Add a new option verbose for malloc debug that is not enabled by default.
This disables all of the info log messages. It turns out these log
messages can add a measurable amount of time and can change the boot up.
Bug: 129239269
Test: Adjusted unit tests pass.
Test: Verified no messages unless verbose option used.
Change-Id: I805cb7c8ecb44de88119574e59d784877cacc383
The media processes already use scudo as their allocator. However, it
doesn't really correctly replace the normal allocation functions, so create
a set of wrappers that allow us to use scudo closer to how jemalloc is used.
This is only a temporary change, and should be removed for the next
release of Android. In that version, we will be using standalone
scudo which won't require this wrapper code.
Bug: 123689570
Test: Ran new bionic unit tests. There are failures, but only with
Test: extensions that scudo does not support.
Change-Id: I0516c23d654a9b6c69b157c5501245d2e0b3d264
There have been several changes since the file was created. Update the
file with latest build. We also sort the symbols by names when they
have the same size so that future updates are easier to review.
Bug: 124521408
Test: Build and inspect symbol ordering
Change-Id: Iedd885b9a87d882ae278a1f117f40b20d064c384
Don't print an extraneous newline character at the end of the include
file if clean_header.py is used in the non-update mode. This is
necessary to achieve consistent results in the update and non-update
modes.
Running clean_header in the non-update mode and redirecting the output
to a file should have the same result as using the update mode and have
the script write to the file directly.
Change-Id: I6b176c5365840d66e4499bacd205f1fa77302a2b
Write to correct dst_file when in update mode. This enables use cases
like the following:
../../../bionic/libc/kernel/tools/clean_header.py -k original-kernel-headers/ -d kernel-headers/ -u linux/ion.h
Previously, we had to cd into kernel-headers/ and then run
../../../../bionic/libc/kernel/tools/clean_header.py -k ../original-kernel-headers/ -d . -u linux/ion.h
because the tool didn't allow the relative path to be different from the
destination path.
Change-Id: I8c5e284ce7a6737d77a2f5ead3e7e5db01317425
The previous refactor left a double call to the initialization of
the loaded hooks. Remove the unnecessary call.
Bug: 129239269
Test: All unit tests pass. No double printing of init messages.
Change-Id: Ie980f2383c75d69f8b06bf9a431bb59caef21188
This makes it easier for tools to find the mapping. I am planning
to use this in crashpad to add HWASAN reports to the minidump.
Bug: http://crbug.com/crashpad/287
Change-Id: I600e551ef26d6ff62849319365d77912afa82fde
c50b6a2b89 redefined the powerof2 macro,
but in a way that that didn't meet the clang_format style guidelines.
Change powerof2 to make clang_format happy.
Test: compiles
Change-Id: Icd04a17f40413b7a416ddcdc080edbc4d3fac87a
With __cpu_model visibility issue fixed in libcrt, we can move x86 and
x86_64 libc to use libcrt as well.
Test: emulator boots
Bug: 122993569
Change-Id: If71c324180010a57e3e9598d758a4d6ab1a3c369
Our strptime was missing `%F`, `%G`, `%g`, `%P`, `%u`, `%V`, and
`%v`. Most of these are already supported upstream (and I've just pulled
their current implementation), but some aren't. We're horribly out of
sync anyway, so I'll upstream the missing pieces and then try to get us
back in sync later.
Test: new tests, but originally found by toybox trying to use %F
Change-Id: Ib1a10801a7a3b9c9189440c3b300109bde535fd9
Bug: http://b/128524141
This signal is used by libprofile-extras to trigger flush of gcov
coverage data.
Test: libprofile-extras in system/extras/toolchain-extras
Change-Id: I77dd5b1d67371a9cfaad54ad60254bfb2dd18ba9
We regressed on this recently: code under the upstream-* directories has
_PATH_BSHELL defined as a call to __bionic_get_shell_path(). In our own
code, we may as well just call it directly.
Bug: https://issuetracker.google.com/129030706
Test: ran tests
Change-Id: Ic2423f521272be95e67f94771772fe8072636ef0
Subtracting one from the smallest value expressable by the provided
variable could cause an underflow operation. In particular, this is
problematic when code similar to:
uint64_t foo = 0;
if (powerof2(foo)) {
...;
}
is run with integer sanitization enabled. The macro would subtract one
from zero, underflowing and triggering the sanitizer.
Make the powerof2() macro ubsan safe, by explicitly handling underflows.
Note: This change DOES NOT make powerof2() accurate. We continue to
falsely return "true" for 0 and negative numbers (see attached tests).
Found while investigating Bug: 122975762
Test: see added testcase
Test: atest ziparchive-tests
Change-Id: I5408ce5c18868d797bcae8f115ddb7c4c1ced81e
We don't need this now that popen always uses O_CLOEXEC, and it's unsafe
because _fwalk takes a lock. (In <= P, the equivalent code walked the
list without a lock in the child.)
Bug: http://b/129156634
Test: ran tests
Change-Id: Ic9cee7eb59cfc9397f370d1dc47ea3d3326179ca
This commit adds missing INTRODUCTED_IN(29) annotations to fdsan.h.
Note: This is not revealed until recently because API level 29 is added
in Mar 14 and the prebuilt binary for versioner hasn't been updated.
Test: ./bionic/tools/versioner/run_tests.py
Change-Id: Ie7bf555bb47c97d15f0c5fa36a76bc6cd64e206b
This commit fixes an inline and non-inline mismatch error caused by
`get_device_api_level_inlines.h`.
Versioner includes both `android/api-level.h` and
`bits/get_device_api_level_inlines.h` in the test. When __ANDROID_API__
is greater than or equal to __ANDROID_API_Q__, `android/api-level.h`
declares a non-inline `android_get_device_api_level()`. On the
contrary, `bits/get_device_api_level_inlines.h` defines a static inline
`android_get_device_api_level()` function. These conflicting
declarations result in compilation error.
This commit fixes the problem by guarding full
`get_device_api_level_inline.h` with
`#if defined(__BIONIC_GET_DEVICE_API_LEVEL_INLINE)` so that
`get_device_api_level_inline.h` can be no-op when it is not properly
included.
Note: This is not revealed until recently because API level 29 is added
in Mar 14 and the prebuilt binary for versioner hasn't been updated.
Test: ./bionic/tools/versioner/run_tests.py
Change-Id: Ia7d5fbdcaf3d98787e60780f6cff2a24016324f5
This commit suppress warnings on pthread_create because clang-r353983
would check the function declaration against the built-in function
defined in llvm/tools/clang/include/clang/Basic/Builtins.def and find a
mismatch.
Note: This is only found by versioner because these files are not system
headers from the perspective of versioner. This warning is ignored in
normal builds because bionic headers are system headers in normal
builds.
Bug: 126457671
Test: lunch walleye-userdebug && make
Change-Id: I3f05ba19861f1b9db55c7c55c4496a845802e831
__hwasan_init() was segfaulting when called from here because it
was calling into libc functions which required more of libc to be
initialized. Instead, call __hwasan_init_static(), which does a
minimal amount of initialization for statically linked executables,
just enough that we can run instrumented code. __hwasan_init() itself
will end up being called later (most likely from a global ctor)
after libc is fully initialized.
We'll need to wait for LLVM r352816+r352823 to land in our toolchain
before landing this.
Change-Id: I12ffc7e08f6dd161e4ff2088f8d56265af7baedf
Call a hwasan hook in the parent return path for vfork() to let hwasan
update its shadow. See https://github.com/google/sanitizers/issues/925
for more details.
Bug: 112438058
Test: bionic-unit-tests
Change-Id: I9a06800962913e822bd66e072012d0a2c5be453d
Bug: 128872105
Test: Ran the android_mallopt.set_allocation_limit_multiple_threads test
Test: a thousand times on taimen.
Change-Id: I67a474c53cd6eda8106feac99aee8e7b0bee1254
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
This hasn't been particularly useful, we haven't used it consistently,
and it has caused trouble.
Test: builds
Change-Id: Ic5b5b5124af98aa8301e602fd75b0eb72a5fc7f6
