In __cxa_finalize, only call fflush(NULL) when the program is exiting, not
when a library is unloaded with dlclose. This change restores behavior
from 2015.
Flushing output is needed when the program exits, but flushing everything
is hazardous at other times because it can block -- fflush(NULL) locks
every file, so it also blocks on read operations.
Bug: http://b/130655235
Test: manual
Change-Id: I2f5ecffa6724bfd98a93d145ab5313c793c01ae6
(cherry picked from commit c5d8c6c6e4)
Bug: http://b/130825973
Test: run affected app on cuttlefish
Change-Id: I776f26f5eaebdfdb1256ff621bd05ef5a90b852a
(cherry picked from commit c7b81108b4)
ANDROID_DLEXT_WRITE_RELRO was inadvertently writing out the RELRO
section of all libraries loaded during a given dlopen() call instead of
only the main library; since the other libraries are loaded at
unpredictable addresses this additional data is rarely useful.
Fix this to only happen when the
ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE flag is being used.
Bug: 128623590
Test: DlExtRelroSharingTest.CheckRelroSizes
Change-Id: I05e8651d06ce2de77b8c85fe2b6238f9c09691ad
(cherry picked from commit 5d10374947)
These symbols were previously provided by Android's out-dated libgcc,
but they're removed/deprecated in upstream libgcc, and also won't be
available in libclang_rt.builtins. We need to provide these methods in
libc itself for compatiblity.
Test: build with these symbols stripped in libgcc
Bug: 29275768
Change-Id: Ie1ccdb711872bf3fc317cb908fed67c9a8955e42
Merged-In: I04a05258c6c06b5a22ead41e148b02792ffbc941
(cherry picked from commit b410d0e69e)
For a recursive or errorcheck PI mutex, the old_owner variable wasn't
being initialized. As a result, unlocking a doubly-locked recursive
mutex owned by another thread decremented the mutex counter. Instead, the
unlock call should fail with EPERM.
Bug: http://b/130841532
Test: bionic-unit-tests
Test: bionic-unit-tests-glibc --gtest_filter='pthread.pthread_mutex_lock*'
Change-Id: I37adb094cb2ce8d51df7b4f48e8d6bc144436418
(cherry picked from commit 4b6c0f5dce)
This reverts commit e4788d4c7e,
which undid this change during the Q betas.
Bug: http://b/120989619
(cherry picked from commit 927fe99692)
Change-Id: Ie8fc0fc0965055f312c2c0cc0f64adb7594ffdb4
Ensure we call realloc@plt rather than (as was previously happening)
inlining realloc into reallocarray, which makes the allocation invisible
to ASan.
Bug: http://b/129989984
Test: objdump
(cherry picked from commit 390be50067)
Change-Id: I0676b70cb9a7d7323252eabfff055c0e806915ef
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)
Enable the use case where we run clean_header.py from outside of
$ANDROID_BUILD_TOP. Previously, this script required the current working
directory to be under $ANDROID_BUILD_TOP. Running it from a different
directory resulted in the following error message:
clean_header.py: error: Not in android tree pointed at by ANDROID_BUILD_TOP (....)
(cherry picked from commit d12d6f67bc)
Bug: 128420573
Change-Id: If07b0345401f5dd35b41876a3838209595bf8ab1
Merged-In: I48210ea1a0033228a9aaa4124d28247b07cee6d4
The function cleanupFile should always return a single value (as opposed
to a tuple or list). In addition, if it encounters an error, it is
expected to return a value that evaluates to False. As it stands,
however, it returns (None, None) in certain error cases. Change this
function to return None, in those cases.
We previously saw the following error message, when we tried to run
clean_header.py on a non-existent file.
Traceback (most recent call last):
File "clean_header.py", line 208, in <module>
b.updateGitFiles()
File "utils.py", line 164, in updateGitFiles
self._writeFile(dst)
File "utils.py", line 136, in _writeFile
f.write(self.new_data[dst])
TypeError: expected a string or other character buffer object
(cherry picked from commit 6d6b4cedd1)
Bug: 128420573
Change-Id: Id1dfab71e7efdee14950520df69f2e35219ee353
Merged-In: I5f717dd1a4388f598f0fd4bfd5e6129017de9095
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)
Adding some benchmarks that keep a certain number of allocation
around. This benchmark should not be used as an absolute for determining
what is a good/bad native allocator. However, it should be used to make
sure that numbers are not completely changed between allocator versions.
Also update the malloc sql benchmark to match the same style as these
new benchmarks.
Bug: 129743239
Test: Ran these benchmarks.
Change-Id: I1995d98fd269b61d9c96efed6eff3ed278e24c97
Merged-In: I1995d98fd269b61d9c96efed6eff3ed278e24c97
(cherry picked from commit 7ec2c8a9b6)
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
Change-Id: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
/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
Change-Id: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
(cherry picked from commit aea5c34423)
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
(cherry picked from commit 8c1a14d4f3)
Change-Id: I88f3e1f205f802ece751aacd63fe7d3cc56f2a5f
Bug: http://b/129728267
Bug: http://b/117167374
This test is now built with XOM (because libm now uses XOM) but it
should also use libclang_rt.builtins since libgcc is not built with XOM.
Test: bionic-unit-tests-static passes (but used to segfault with XOM
exceptions without this change).
Change-Id: I0b1dfe52e48db5f5e9386c7722ecd91e155be56f
ANDROID_DLEXT_WRITE_RELRO was causing the GNU RELRO sections of
libraries to become corrupted if more than one library was being loaded
at once (i.e. if the root library has DT_NEEDED entries for libraries
that weren't already loaded). The file offset was not being correctly
propagated between calls, so after writing out the (correct) RELRO data
to the file, it was mapping the data at file offset 0 for all libraries,
which corrupted the data for all but one of the libraries.
Fix this by passing file_offset as a pointer the same way that
phdr_table_map_gnu_relro does.
Bug: 128623590
Test: tbd
Change-Id: I196cd336bd5a67454e89fd85487356b1c7856871
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
