gtest's Message class has a special handler for operator<< of wchar_t*
to convert it to UTF-8, but it doesn't have one for a single wchar_t or
for a char16_t* string. It delegates these to std::stringstream, which
as of a libc++ upgrade, deletes its operator<< for char16_t and
wchar_t. See wg21.link/p1423r3.
Bug: http://b/175635923
Test: m MODULES-IN-bionic
Change-Id: I8307663b72855cfc0b91d7f63993f1f6fe028b8e
The bionic benchmarks set the decay time in various ways, but
don't necessarily restore it properly. Add a new method for
getting the current decay time and then a way to restore it.
Right now the assumption is that the decay time defaults to zero,
but in the near future that assumption might be incorrect. Therefore
using this method will future proof the code.
Bug: 302212507
Test: Unit tests pass for both static and dynamic executables.
Test: Ran bionic benchmarks that were modified.
Change-Id: Ia77ff9ffee3081c5c1c02cb4309880f33b284e82
We've talked about this many times in the past, but partners struggle to
understand "expected 38, got 22" in these contexts, and I always have to
go and check the header files just to be sure I'm sure.
I actually think the glibc geterrorname_np() function (which would
return "ENOSYS" rather than "Function not implemented") would be more
helpful, but I'll have to go and implement that first, and then come
back.
Being forced to go through all our errno assertions did also make me
want to use a more consistent style for our ENOSYS assertions in
particular --- there's a particularly readable idiom, and I'll also come
back and move more of those checks to the most readable idiom.
I've added a few missing `errno = 0`s before tests, and removed a few
stray `errno = 0`s from tests that don't actually make assertions about
errno, since I had to look at every single reference to errno anyway.
Test: treehugger
Change-Id: Iba7c56f2adc30288c3e00ade106635e515e88179
Change our handful of `constexpr static`s to the much more common
`static constexpr`. It's easier to "follow existing style" when there
aren't two existing styles to copy from, and all else being equal,
"majority wins" :-)
Test: treehugger
Change-Id: Ifbf0f62ab84c9450bf9c2e49e96915c126fd20c4
Under some circumstances, it's possible to fail the enable allocation
limit android_mallopt call. Increase the total allowed time for the
function to complete.
In addition, if the enable fails, allow another limit call to succeed
in the future.
Finally, change the limit test to use _exit instead of exit.
Bug: 291672185
Test: Ran limit test thousands of times.
Test: Forced the limit to fail and verified the second call passes.
Change-Id: I0948e6fd97231a7538b9b82b76f0a207386681b1
The set_allocation_limit_multiple_threads test could fail every
once in a while. So rewrite slightly so that the tests wait until
all of the threads are running before letting them start.
I also refactored the code to use std::thread instead of the raw
pthread functions.
Bug: 291672185
Test: Ran the test thousdands of times.
Change-Id: Ia0bdef93d58e0ff8266e551ed4a32e14ff829581
This new mallopt cause statistics of the allocator to be printed in
the log.
Add a stats print for jemalloc.
This is designed to be used as part of a dumpsys meminfo --XXXX
option so that it's easier to get information about apps that
have an unusual memory footprint.
Test: Unit tests pass.
Test: Ran on a device using jemalloc and verified log data.
Test: Ran on a device using scudo and verified log data.
Change-Id: I6fa44ce619c064b2596fbbb478c231994af94f4c
This is a new mallopt option that will force purge absolutely
everything no matter how long it takes to purge.
Wrote a unit test for the new mallopt, and added a test to help
verify that new mallopt parameters do not conflict with each other.
Modified some benchmarks to use this new parameter so that we can
get better RSS data.
Added a new M_PURGE_ALL benchmark.
Bug: 243851006
Test: All unit tests pass.
Test: Ran changed benchmarks.
Change-Id: I1b46a5e6253538108e052d11ee46fd513568adec
If this is a low ram device, then do not run these tests. Otherwise,
verify that memory returned from the allocator is zero.
Bug: 171429763
Bug: 264539505
Bug: 265431478
Test: New unit tests pass on scudo.
Test: New unit tests fail on original jemalloc.
Test: New unit tests pass on jemalloc that always zeroes memory.
Test: New unit tests are skipped on low ram device.
Test: Ran unit tests atest CtsBionicTestCases in above scenarios.
Change-Id: Id62ab74f649c0f7c14a951235fe79972926ecec0
Even though glibc has mallopt, there is no way to guarantee that
we use an invalid argument. Since this test is only really useful
for bionic, only run it on bionic.
Test: Ran glibc and verified the test is skipped.
Change-Id: If991e8804b21c83f3d7e3b15a0b60e48da331567
This patch introduces GWP-ASan system properties and environment
variables to control the internal sampling rates of GWP-ASan. This can
be used for:
1. "Torture testing" the system, i.e. running it under an extremely
high sampling rate under GWP-ASan.
2. Increasing sampling remotely to allow further crash report
collection of rare issues.
There are three sets of system properites:
1. libc.debug.gwp_asan.*.system_default: Default values for native
executables and system apps.
2. libc.debug.gwp_asan.*.app_default: Default values for non-system
apps, and
3. libc.debug.gwp_asan.*.<basename/app_name>: Default values for an
individual app or native process.
There are three variables that can be changed:
1. The allocation sampling rate (default: 2500) - using the environment
variable GWP_ASAN_SAMPLE_RATE or the libc.debug.gwp_asan.sample_rate.*
system property.
2. The process sampling rate (default: 128 for system apps/processes, 1
for opted-in apps) - using the environment variable
GWP_ASAN_PROCESS_SAMPLING or the libc.debug.gwp_asan.process_sampling.*
system property,
3. The number of slots available (default: 32) - using the environment
variable GWP_ASAN_MAX_ALLOCS or the libc.debug.gwp_asan.max_allocs.*
system property.
If not specified, #3 will be calculated as a ratio of the default
|2500 SampleRate : 32 slots|. So, a sample rate of "1250" (i.e. twice as
frequent sampling) will result in a doubling of the max_allocs to "64".
Bug: 219651032
Test: atest bionic-unit-tests
Change-Id: Idb40a2a4d074e01ce3c4e635ad639a91a32d570f
We've added mallinfo and mallinfo2 to musl, enable the bionic tests
for it. Also modify the comparison test to explicitly cast the
mallinfo fields to size_t, as they are ints in musl.
Bug: 190084016
Test: bionic-unit-tests-glibc --gtest_filter=malloc.*
Change-Id: Ib2a1d6cf698de817c314a61fe29fda85edabb9ed
clang was configured to force 16 byte alignments on allocations > 8
for 64 bit. Unfortunately, we never updated our alignment test to
verify this behavior. So this finally adds these new restrictions.
In addition, when GWP-ASan is enabled, it will take over allocations
from the native allocator. In order to make sure that GWP-ASan also
obeys these alignment checks, add a test that forces GWP-ASan on and
runs the alignment check test.
Test: Ran unit tests on a flame using scudo (both 32 bit and 64 bit).
Test: Ran unit tests on a flame using jemalloc (both 32 bit and 64 bit).
Change-Id: I87a20b9c2f32b9d207f36437d291ed44247dcbd1
When calling android_mallopt using M_INITIALIZE_GWP_ASAN, nothing
was being returned. Fix this, add a test, and also refactor the
code a bit so dynamic and static share the same code.
Test: Unit tests pass in dynamic and static versions.
Test: Passed using both jemalloc and scudo.
Change-Id: Ibe54b6ccabdbd44d2378892e793df393978bc02b
Modify bionic unit tests that are built for glibc so that they also
build against musl. They don't all pass though:
With glibc:
2 SLOW TESTS
4 TIMEOUT TESTS
313 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
With musl:
11 SLOW TESTS
11 TIMEOUT TESTS
363 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
Bug: 190084016
Test: m bionic-unit-tests-glibc with musl
Test: atest bionic-unit-tests-static
Test: atest --host bionic-unit-tests-glibc with glibc
Change-Id: I79b6eab04fed3cc4392450df5eef2579412edfe1
The allocator for the native bridge is not necessarily going to
allocate the slack data.
Bug: 189606147
Test: Ran on non-native bridge and verified test isn't skipped.
Test: Ran on native bridge and verified test is skipped.
Change-Id: Ia1555be0e9f55896af7ca81830605367133c44a1
This works around buggy applications that read a few bytes past the
end of their allocation, which would otherwise cause a segfault with
the concurrent Scudo change that aligns large allocations to the right.
Because the implementation of
android_set_application_target_sdk_version() lives in the linker,
we need to introduce a hook so that libc is notified when the target
SDK version changes.
Bug: 181344545
Change-Id: Id4be6645b94fad3f64ae48afd16c0154f1de448f
Introduces new heap-zero-init API. We've realised that it's better to be
able to individually control MTE and heap zero-init. Having
heap-zero-init not be controllable without affecting MTE affects our
ability to turn off heap-zero-init in zygote-forked applications.
Bug: 135772972
Test: On FVP: atest -s localhost:5555 malloc#zero_init \
Test: malloc#disable_mte heap_tagging_level
Change-Id: I8c6722502733259934c699f4f1269eaf1641a09f
These were only available internally via android_mallopt(), but they're
likely to be needed by more code in future, so move them into mallopt().
This change leaves the android_mallopt() options for now, but I plan on
coming back to remove them after I've switched the handful of callers
over to mallopt() instead.
Bug: http://b/135772972
Test: treehugger
Change-Id: Ia154614069a7623c6aca85975a91e6a156f04759
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
Introduce an android_mallopt(M_DISABLE_MEMORY_MITIGATIONS) API call
that may be used to disable zero- or pattern-init on non-MTE hardware,
or memory tagging on MTE hardware. The intent is that this function
may be called at any time, including when there are multiple threads
running.
Disabling zero- or pattern-init is quite trivial, we just need to set
a global variable to 0 via a Scudo API call (although there will be
some separate work required on the Scudo side to make this operation
thread-safe).
It is a bit more tricky to disable MTE across a process, because
the kernel does not provide an API for disabling tag checking in all
threads in a process, only per-thread. We need to send a signal to each
of the process's threads with a handler that issues the required prctl
call, and lock thread creation for the duration of the API call to
avoid races between thread enumeration and calls to pthread_create().
Bug: 135772972
Change-Id: I81ece86ace916eb6b435ab516cd431ec4b48a3bf
The SYNC tagging level enables stack trace collection for allocations and
deallocations, which allows allocation and deallocation stack traces to
appear in tombstones when encountering a tag check fault in synchronous tag
checking mode.
Bug: 135772972
Change-Id: Ibda9f51b29d2c8e2c993fc74425dea7bfa23ab1e
The tag level may now be async, which is now the default. When the tag level
is set to none, memory tagging is disabled in the allocator using the new
API proposed in https://reviews.llvm.org/D70762 .
Bug: 135772972
Change-Id: I847f5822a70913c446ed9ffa13792177bbfc96af
Scudo implemented malloc_info for the primary allocator, so add some
small amount of validation.
Test: Ran the malloc_info tests and verified they pass.
Change-Id: Ib7c609e46cc1ed73fa5c042df92fa9b568880f21
The alloc after fork is a test that should pass, but jemalloc
doesn't right now. Leave the test disabled until the native
allocator can pass this.
Test: Ran the test 1000 times on glibc to verify it passes.
Test: On device, verified it does not run.
Change-Id: I482af4db2fee81c947ac081c7a6f25a2aff80350
This patch refactors heapprofd_malloc to make it easier to reuse the
reserved signal for multiple purposes. We define a new generic signal
handler for profilers, which dispatches to more specific logic based on
the signal's payload (si_value).
The profiler signal handler is installed during libc preinit, after
malloc initialization (so races against synchronous heapprofd
initialization need not be considered). In terms of code organization, I
copied the existing approach with a loosely referenced function in
bionic_globals.h. Do tell if you'd rather a different approach here.
The profileability of a process is quite tied to the malloc
files/interfaces in bionic - in particular, it's set through
android_mallopt. I do not change that, but instead introduce a new
android_mallopt option to be able to query profileability of the
process (which is now used by the new profiler signal handler). As part
of that, gZygoteChildProfileable is moved from heapprofd_malloc to
common (alongside gZygoteChild).
I've removed the masking and reraising of the heapprofd signal when
racing against malloc_limit init. We're ok with taking a simpler
approach and dropping the heapprofd signal in such an unlikely race.
Note: this requires a corresponding change in heapprofd to use sigqueue()
instead of kill(), as the latter leaves the si_value uninitialized(?) on
the receiving side.
Bug: 144281346
Change-Id: I93bb2e82cff5870e5ca499cf86439860aca9dfa5
Bug: 146576216
Test: Ran the test on jemalloc and glibc.
Test: Ran the test on scudo and verified that failed without the align
Test: change.
Change-Id: I31a96f8672c6bce2423210300288a13df1eda42a
When using a FILE object for some malloc debug functions, calling
fprintf will trigger an allocation to be put in the object. The problem
is that these allocations were not allocated by the malloc debug
wrapper and they get freed during the fclose as if they are malloc
debug allocation. In most cases, the code will detect the bad pointer
and leak the memory, but it might also cause a crash.
The fix is to avoid using fprintf so that no allocations are made
in the object that survive and need to be freed in the fclose call.
Change the MallocXmlElem.h to use a file decsriptor not a FILE object.
Add new unit and system tests to detect this case.
Bug: 143742907
Test: Ran unit and system tests.
Test: Ran bionic unit tests.
Change-Id: I524392de822a29483aa5be8f14c680e70033eba2
As the first pass, the malloc_info for scudo doesn't return anything.
This feature is hardly ever used, so this seems fine for the first
revision.
Bug: 137795072
Test: Ran unit tests on a taimen using scudo and a taimen using jemalloc.
Change-Id: I675386ae17ba5505c27bd9da12c60242d795464a
Instead of having platform directories directly include the
private header, create a platform header directory and export it.
Bug: 130763340
Test: Builds.
Change-Id: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
Merged-In: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
(cherry picked from commit 8f582ef2f8)
In order for cts to enumerate tests, even tests that are not supported
need to run and be skipped. Make this true for pvalloc/valloc
tests.
Change-Id: I863a179ee6810824a7117f44cc9aa3f86d01eb5b
Test: Ran tests in 32 bit and 64 bit and verified tests are skipped in
Test: 64 bit and run properly in 32 bit.
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
Merged-In: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
(cherry picked from commit 125d32cb46)
