| Age | Commit message (Collapse) | Author |
|---|
|
qt-qpr1-release
Change-Id: I67c50098aba9d711bf100e72fa95763ba844a9d3
|
|
am: 5cda74e065
Change-Id: I6fdf747408e96c1f99c4544e94a97835c8588d19
|
|
On systems where the tcache is disabled, the tcache clear option will
fail, and not really do a purge.
Bug: 137037462
Bug: 136236080
Test: Built taimen as malloc svelte and verified the M_PURGE mallopt
Test: call failed before this fix and passes afterwards.
Change-Id: Ib30e5f3e083a9c6d046adff30f2aa7eacaf6df10
Merged-In: Ib30e5f3e083a9c6d046adff30f2aa7eacaf6df10
(cherry picked from commit 3d0bafb945bc9e39ddc84a0167e713b8e70dc135)
|
|
qt-qpr1-release
Change-Id: I37ff98127f03694e199e8acae723c1f5f1a9e04e
|
|
A proposed set of changes:
https://android-review.googlesource.com/q/topic:"no-dup-hwasans"
will cause the HWASAN runtime to be moved from /system/lib64 to
/system/lib64/bootstrap. This causes a problem in the case where libc is built
with HWASAN but init is not built with HWASAN. In this case, libc.so will have
a DT_NEEDED dependency on the HWASAN runtime but init will not. Currently,
init and other bootstrap executables arrange to load bootstrap libraries by
setting rpath, but rpath only has an effect on libraries directly depended
on by the main executable, not libraries indirectly depended on by it. This
means that the loading of the HWASAN runtime will fail.
Instead of relying on rpath to find the bootstrap libraries, modify the
bootstrap linker so that it searches the bootstrap library directory after
searching the rpath.
Bug: http://b/134503977
Test: Builds
Change-Id: I297be32e04ecd316ee12b8e694588e1249e2bb89
Merged-In: I297be32e04ecd316ee12b8e694588e1249e2bb89
(cherry picked from commit ea11be0cc85cb5355ca7ed4ee8736ea52b72e38d)
|
|
qt-qpr1-release
Change-Id: Ib531f950c78b81e0b3c52961f3da9ee9836e2622
|
|
am: fe0fbcff7f
Change-Id: I74af54311bd19b9b4a5258ec45c85436da34d033
|
|
On cf_x86_phone-userdebug, both of the unwind through signal
tests fail. This has been failing forever, but seems to have suddenly
become an issue, so disable while I try to figure out why this is happening.
Bug: 132763120
Test: Ran on emulator and verified tests are skipped.
Change-Id: Iafc227d972a7783e94c701d73078c9570cea288e
Merged-In: Iafc227d972a7783e94c701d73078c9570cea288e
(cherry picked from commit d424fafbce4b60f4e5c38981af99c05d07727ed4)
|
|
am: 51ad27180b
Change-Id: Ia96df84946fe463d7f452f22620bb80d68f91996
|
|
am: 020681fec7
Change-Id: I8e84f2e1f5ce57d9ed6c05637328f5d2d66a0e4c
|
|
|
|
am: 2a67b023bd
Change-Id: Ib5ce506478de240dbce534fdc7a12e773ac187a7
|
|
I wrote a new unit test that would fail on the old version of the
code.
On a walleye big cpu, this costs about 40ns-50ns (going from ~430ns to ~480ns).
I think this is an acceptable performance degradation.
Bug: 131867816
Test: New unit tests pass.
Change-Id: I4c0f4373fb0694bf29c3824dbb1224a8a17e211e
Merged-In: I4c0f4373fb0694bf29c3824dbb1224a8a17e211e
(cherry picked from commit d269fcc935b276502b9e47a575d76693fe1b8455)
|
|
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
|
|
Fix too small buffer for the startup property not accounting for the
prefix.
Bug: 131893397
This is a cherry-pick of f6d221eeed66c975fb05589a171fe4a05c0d35f7.
Change-Id: Iad2398bc09c61b1144430bcbef58e5a832b85b0a
Merged-In: Iad2398bc09c61b1144430bcbef58e5a832b85b0a
|
|
am: 2a24f6bd5f
Change-Id: I24bcda8a0754bc34a46e7a5e11954a074ee79544
|
|
am: bffe6f16a8
Change-Id: Ifa811cb1cba283e0c67fa3fa93720b0811a801ac
|
|
|
|
Test: manual testing
Bug: 130267141
Bug: 29275768
Merged-In: If50420c05d36e6f680a36673e7c26ca7deb93b28
Change-Id: I1e74c7b13ce0e0fa0e9c98cf9139f85e36b0645d
(cherry picked from commit 7ac2afbde37258b8fc489f24bd1fcbf2cac18e39)
|
|
The locking can fail in a couple of ways:
- A concurrent fread from an unbuffered or line-buffered file flushes
the output of other line-buffered files, and if _fwalk locks every
file, then the fread blocks until other file reads have completed.
- __sfp can initialize a file lock while _fwalk is locking/unlocking it.
For now, revert to the behavior Bionic had in previous releases. This
commit reverts the file locking parts of commit
468efc80da2504f4ae7de8b5e137426d44dda9d7.
Bug: http://b/131251441
Bug: http://b/130189834
Test: bionic unit tests
Change-Id: I9e20b9cd8ccd14e7962f7308e174f08af72b56c6
(cherry picked from commit c485cdb0249415b8aee5968b2b8854921e152854)
|
|
am: 125d32cb46
Change-Id: I4c971ef382f835fc0a308487d167c45b7414e119
|
|
Also change the names of some of the functions to make it very obvious
that the functions being called are in je code.
Write new test to make sure mallinfo and malloc_info match.
Bug: 131864803
Test: New unit tests pass (along with all other bionic unit tests).
Change-Id: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
|
|
am: 58567dcd78
Change-Id: Ifd5dbf7e92788873827814445388e99ab6503e7b
|
|
Bug: 131362671
Test: Ran bionic unit tests.
Test: Wrote a test that did a purge and verified that the tcache->ncached
Test: number went from 3 to 0. Also verified that mallinfo reflects the
Test: cached entries being flushed.
Change-Id: I64e35618fa3b523cf29bdaceedef676abe440dd3
(cherry picked from commit 0f710fd59346312b4e351e9d3c956bc804ff02b2)
|
|
|
|
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 c5d8c6c6e47a7f5fd0c3db2a48004be1030cf753)
|
|
Bug: http://b/130825973
Test: run affected app on cuttlefish
Change-Id: I776f26f5eaebdfdb1256ff621bd05ef5a90b852a
(cherry picked from commit c7b81108b48d213ef3eb8f296440ada893e9ac5d)
|
|
|
|
|
|
|
|
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 5d10374947824c60d524e812172ae60f30a51fde)
|
|
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 b410d0e69ef6f545c7652ee0e4cf7b4dd4d2c38a)
|
|
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 4b6c0f5dce5ad8d93e4e707977e09153a5399139)
|
|
This reverts commit e4788d4c7e842b0ca24363ebc5544a16c9e3b185,
which undid this change during the Q betas.
Bug: http://b/120989619
(cherry picked from commit 927fe99692b1edc723e74bfc17ed718a84ddc6fd)
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 390be50067c03524b420cae83fd97992f26fa754)
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 3aadc5e80a5e2cf6b6760ed90d528709223bb449)
|
|
|
|
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 d12d6f67bca790696679db46cdc306eba3122e7c)
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 6d6b4cedd16c3b4d6de114c622739fc5d52f4c57)
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 5225b342f0810c027df3d09fbbcef4d324b19b93)
|
|
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 7ec2c8a9b6f9a050d2ac9e0c35f0a631573f3de6)
|
|
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 aea5c344230b292c56cf96f77b33f6f35f9b30be)
|
|
* dlsym: call __tls_get_addr for TLS symbols
* dladdr: skip TLS symbols
Bug: b/123772574
Test: bionic unit tests
Change-Id: I59a8bc4a7d455e1018b0d577b027b6417c8487cd
(cherry picked from commit e4d620bc805aa675924a4f50c7179195126d65a6)
|
|
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 8c1a14d4f358a8135e0c0632da6d40c37192c0c2)
Change-Id: I88f3e1f205f802ece751aacd63fe7d3cc56f2a5f
|
|
am: 5da3333d1b
Change-Id: I25c9f2606c7d692fb1b7d40d8205122b27f74dda
|
|
c950489599
am: ce62c05753
Change-Id: I234ee6e837fe2609918cee82121aa3994afbd4d8
|
|
am: c950489599
Change-Id: Iea5e24a6a46094cf87d77852ccc8b124c4bdb075
|
