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
Many clang-analyzer-unix.Malloc warnings from this file
are leaks after test failure and we can ignore them.
Clang-tidy cannot compile this file within 90 second
time limit most of the time, which makes maintaining
it free of clang-tidy warnings impractical.
Bug: 259995529
Test: presubmit; make tidy-bionic-tests_subset
Change-Id: I532c761744b0400dec33363a3235f81ac7fbbb30
* changes:
Expose unwinder APIs in NDK stubs for R and up.
Use abi::__cxa_demangle declared in cxxabi.h
__cxa_atexit_test: declare __cxa_atexit and __cxa_finalize
After updating libc++, they're no longer declared in cxxabi.h, so the
test must declare them locally.
8bd0dc5bfe
Temporarily use a return type of "int" to avoid a Clang error about
conflicting return types.
Bug: http://b/175635923
Test: treehugger
Change-Id: I16ba3dc8cc84cc18ee7fbfe9d2e3fa0cd4eefeae
The libtest_empty.so was built by the "libtest_empty" build rule, and
the other files are copies of that with small edits made by the toybox
hexedit tool. I worked out what to edit in each case from a combination
of "what does the name imply?" and "what does a diff of the xxd output
of the corresponding two arm64 files show?".
I failed to produce a working (by which I mean "failing") local-tls
file despite my best efforts. I'm not sure what exactly it was about the
gold-generated files we didn't like, because the commentary implies that
this would be problematic:
39: 0000000000000004 4 TLS LOCAL DEFAULT 12 tls_var_2
But it loads without complaint.
Test: ran locally
Change-Id: I3b9b2b4db1f8827243541cf13380c6ceb840f123
We'll want to come back to this once either Zcmp's push/pop instructions
or V's vector loads/stores are available. But for now, we have no >64b
stores.
But at least this builds.
Test: treehugger
Change-Id: I9503e890cacb198f4ba987bfc92f6eff21c290b0
This commit disables MemtagNoteTest#SEGV when running
on native bridge.
Bug: http://b/242170715
Test: run arm64 Bionic tests on T Emulator
Change-Id: I8ae99c5ba22f09a8d7e751f8bb4938894abe231f
The PRNG seeder daemon is introduced in TM-QPR2 which can lead to
breakage running Android 13 CTS tests depending on when the platform
and CTS tests are built.
Fix: 253185870
Test: run cts --module CtsBionicTestCases
Change-Id: I94fa0aa2f32b09222aee08891e7643bf14d1a204
riscv64 hates nans. From the spec: "Except when otherwise stated, if the
result of a floating-point operation is NaN, it is the canonical NaN.
The canonical NaN has a positive sign and all significand bits clear
except the MSB, a.k.a. the quiet bit."
This broke our tests here because the float-to-double instruction isn't
one of the "otherwise stated" cases, so it turns -nanf() into +nan().
The sign manipulation instructions are "otherwise stated" cases, though,
so as long as we avoid a conversion we're fine. And we didn't actually
_need_ a float here (pretty much by definition, since varargs means you
always end up with a double anyway), so we can just simplify things and
switch to using doubles directly to fix the tests.
Test: bionic-unit-tests-static
Change-Id: I13aa452dd6cc8708275f7676b37fc772b37a7b32
This is mainly just to match what we have for arm64.
The test failures before and after this change are all for the long
double variant, which this change doesn't touch. (The problem there is
that clang is calling `__fixtfdi` for the cast in lrintl(), but that
doesn't respect the current rounding mode, which lrintl() is required
to do. `#pragma STDC FENV_ACCESS ON` doesn't fix this, so there's going
to be some llvm work needed to fix this.)
I've replaced the ASSERTs with EXPECTs in the relevant test to ensure
we're checking all the other assertions despite the `long double`
failures.
Test: bionic-unit-tests-static
Change-Id: Ia24bf21619631b6f8b3b607d30536011bb4cd826
Musl doesn't export __SIGRTMIN, and it is being removed from the
Android wrappers to avoid accidentally referencing bionic's
reserved signals when compiling against musl.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native -k
Change-Id: I342666a17abc31bbc57b383b5cc881c2752886f7
Group riscv64 with arm/arm64, and allow for the fact that there's no
FE_DENORMAL in the riscv64 spec.
Test: fenv.*
Change-Id: Ibf188bcedffd092a7ef1555fa2762e249e1f9845
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: m
Change-Id: I02cf117f67bda74516e4de8cd6f4c05efdb9a85b
I haven't found this explicitly stated anywhere, but it's how our
existing implementations behave, and it seems obviously implied by
the word "entire" in POSIX's claim that fenv_t "Represents the entire
floating-point environment".
Test: treehugger
Change-Id: Ic8fc993775b4ded57dc88766a7d24d0954f3b56d
(And all other new architectures.)
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
Change-Id: Iceb2dd16c738302624980179788c4a2e68b797ed
I've never been able to repro the flake myself (in hundreds of thousands
of runs), but it's certainly possible that a byte of the cookie is
already zero. So let's invert the byte we plan to corrupt rather than
set it to zero.
Bug: http://b/202948861
Test: treehugger
Change-Id: Iccd552fe302d6c01e376819d23c11a308e03acdb
(cherry picked from commit 23ce50c172)
Upstream musl libc defines sysinfo.uptime as unsigned long, while the
kernel and glibc define it as long. Cast it to long for the
comparision.
Bug: 190084016
Test: bionic-unit-tests-glibc
Change-Id: Ib322472d512a9a7474a936e33f35523e1dc995d9
I've never been able to repro the flake myself (in hundreds of thousands
of runs), but it's certainly possible that a byte of the cookie is
already zero. So let's invert the byte we plan to corrupt rather than
set it to zero.
Bug: http://b/202948861
Test: treehugger
Change-Id: Iccd552fe302d6c01e376819d23c11a308e03acdb
At the time I added <stdio_ext.h>, I just added what was on the man
page (which matched glibc), not realizing that musl and glibc had
slightly different functionality in their headers.
The toybox maintainer came up with a legitimate use case for this, for
which there is no portable workaround, so I'm adding it here. I'm not
adding the other functions that are in musl but not glibc for lack of a
motivating use case.
Bug: http://lists.landley.net/htdig.cgi/toybox-landley.net/2022-April/020864.html
Test: treehugger
Change-Id: I073baa86ff0271064d4e2f20a584d38787ead6b0
This tests cover stack tagging setup in response to NT_MEMTAG_STACK and
vfork and longjmp support.
Bug: b/174878242
Test: fvp_mini with ToT LLVM
SANITIZE_TARGET="memtag_heap"
SANITIZE_TARGET="memtag_heap,memtag_stack"
Change-Id: I7fee03d901092d9428d86a6fab6bef4e2e3b51eb
Coming to C23 via WG14 N2630.
This one is a little interesting, because it actually changes existing
behavior. Previously "0b101" would be parsed as "0", "b", "101" by these
functions. I'm led to believe that glibc plans to actually have separate
versions of these functions for C23 and pre-C23, so callers can have the
behavior they (implicitly) specify by virtue of which -std= they compile
with. Android has never really done anything like that, and I'm pretty
sure app developers have more than enough to worry about with API levels
without having to deal with the cartesian product of API level and C
standard.
Therefore, my plan A is "if you're running on Android >= U, you get C23
behavior". My plan B in the (I think unlikely) event that that actually
causes trouble for anyone is "if you're _targeting_ Android >= U, you
get C23 behavior". I don't think we'd actually want to have two versions
of each of these functions under any circumstances --- that seems by far
the most confusing option.
Test: treehugger
Change-Id: I0bbb30315d3fabd306905ad1484361f5d8745935
Coming to C23 via WG14 N2630, and already in glibc.
We're still missing clang support for %b and %B in format string checking,
but it's probably easier to fix this first. (Apparently GCC already has
support because of glibc.)
Test: treehugger
Change-Id: Ie8bfe4630d00c50e1d047d6756a7f799205356db
The FILE::_read function pointer takes an int rather than a size_t, so
we need to be careful to break large reads up for it.
fwrite() hasn't (yet) been optimized in this way, so it's immune for
now, but add the corresponding write test anyway.
Seeking already uses a off64_t function pointer where possible, so I
don't think there's anything more to be done there.
No other function pointers in FILE are relevant.
Bug: https://issuetracker.google.com/240139009
Test: treehugger
Change-Id: Ife2537e10f178bb0d980719592539f4b00b67031
It came up on the musl mailing list that there's not actually any need
to iterate over the directory entries:
https://www.openwall.com/lists/musl/2022/07/27/1
This lets us reuse the code for "online" processors in the
implementation of "configured" processors. The question of whether
"configured" should correspond to Linux's "possible" or "present" isn't
obvious to me, but the distinction seems unlikely to matter on mobile
devices anyway, and that's a trivial change should it ever be needed.
Plus the motivating argument from the person who brought this up was
that callers asking for "configured" processors are probably asking for
an upper bound, which sounds convincing to me.
Test: treehugger
Change-Id: I0d4e13538dc6b09a6dba520d9ac24f436906f7c0
For correct %z output tzcode requires tm struct to be modified by
mktime call or be output of localtime. But as TM_ZONE is null, we
are comparing against +0000.
See https://mm.icann.org/pipermail/tz/2022-July/031674.html
Europe/Lisbon test is added to confirm that current implementation
deviates from libc specification and uses more than just tm_isdst
to find out a time zone's offset.
Bug: 239128167
Test: adb shell /data/nativetest64/bionic-unit-tests-static/bionic-unit-tests-static
Test: adb shell /data/nativetest/bionic-unit-tests-static/bionic-unit-tests-static
Change-Id: Ic27775c840467c4e9ef55bc730a313709372314b
tzdata now has transitions up to the year 2100. Added test to make
sure that dates beyond that are handled properly too.
Bug: 25413083
Test: see system/timezone CL
Change-Id: I02ea04b2c5cfb47bde5fb05f108113901ea33a39
GWP-ASan stress tests can take a while, especially under HWASan.
Bug: 238585984
Test: sleep(100) in one of the tests, and then 'atest bionic-unit-tests'
Change-Id: Ibd983da1c8fd06cffed756cf3b24523f4671d49e
This reverts commit 4e013233b8.
Issue was in unexpected returned fd and errno value combination.
See comments in bionic.cpp and time_test.cpp.
Bug: 236967833
Fix: 236967833
Test: atest CtsBionicTestCases
Test: atest toybox-tests
Change-Id: I51b3e1527ff16b2a6ea4d6fedf8102019f7fd896
Adds persistent sysprops for test infra usage, and adds the tests for
the sysprops.
The test does some fancy flocking in order to restore any existing
GWP-ASan sysprop usage in the test cleanup.
Bug: 236738714
Test: atest bionic-unit-tests
Change-Id: I8956296d39c98ce8c7dd0a703b240530d8ad48db
Upstream has renamed tzsetlcl to tzset_unlocked. As bionic's
implementation of tzset_unlock differs from upstream, these changes were
skipped.
Also, upstream has removed constants (SECSPERMIN, etc) from tzfile.h. As
they are used in strptime.c, I've decided to leave them in tzfile.h and
to not bring them into strptime.c.
HAVE_TZNAME and USG_COMPAT flags semantics were updated, thus setting
their values to 2 in Android.bp file. See
1a27ec76bc
* 4742526b7e
and 0e8f0b06ac
were picked up, which are not part of 2022a.
Changes were applied using following commands:
1) Checkout tzcode repo
2) Prepare patches for all tzcode file using
git diff 2016g 2021e -- <file-name> > <file-name-patch>
3) Apply these patches to files in bionic using
patch -p1 <file-name> <file-name-patch>
Bug: 25413083
Test: CtsLibcoreTestCases
Test: CtsLibcoreOjTestCases
Test: CtsBionicTestCases
Change-Id: I9aba4cbeab30171a32f94d20c8e4057804a4c01f
With memtag_stack, each function is responsible for cleaning up
allocation tags for its stack frame. Allocation tags for anything below
SP must match the address tag in SP.
Both vfork and longjmp implement non-local control transfer which
abandons part of the stack without proper cleanup. Update allocation
tags:
* For longjmp, we know both source and destination values of SP.
* For vfork, save the value of SP before exit() or exec*() - the only
valid ways of ending the child process according to POSIX - and reset
tags from there to SP-in-parent.
This is not 100% solid and can be confused by a number of hopefully
uncommon conditions:
* Segmented stacks.
* Longjmp from sigaltstack into the main stack.
* Some kind of userspace thread implementation using longjmp (that's UB,
longjmp can only return to the caller on the current stack).
* and other strange things.
This change adds a sanity limit on the size of the tag cleanup. Also,
this logic is only activated in the binaries that carry the
NT_MEMTAG_STACK note (set by -fsanitize=memtag-stack) which is meant as
a debugging configuration, is not compatible with pre-armv9 CPUs, and
should not be set on production code.
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more test in a separate change)
Change-Id: Ibef8b2fc5a6ce85c8e562dead1019964d9f6b80b
Musl doesn't have close_range, skip the test.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I7ed485f2d0ec08358c856430b7c4c45fbe45a39f
This test tried to be lazy and test both getmntent() and getmntent_r()
in the same test, but that led to an implicit assumption that /proc
isn't the first mount returned.
This new version is quite a bit more thorough than the old. It does
assume that the mount list doesn't change while the test is running, but
that seems like a reasonable assumption to make during CTS?
Bug: https://issuetracker.google.com/230228681
Test: treehugger
Change-Id: I5c5f0b86ae1c4df9a2ce69d48e1c3accb42c687b
(cherry picked from commit 1e393b0699)
This test tried to be lazy and test both getmntent() and getmntent_r()
in the same test, but that led to an implicit assumption that /proc
isn't the first mount returned.
This new version is quite a bit more thorough than the old. It does
assume that the mount list doesn't change while the test is running, but
that seems like a reasonable assumption to make during CTS?
Bug: https://issuetracker.google.com/230228681
Test: treehugger
Change-Id: I5c5f0b86ae1c4df9a2ce69d48e1c3accb42c687b
See:
https://man7.org/linux/man-pages/man2/close_range.2.html
Note: 'man close_range' documents 'flags' as unsigned int,
while glibc unistd.h as just 'int'. Picking 'int' to match glibc,
though it probably doesn't matter.
BYPASS_INCLUSIVE_LANGUAGE_REASON=man is a cli command
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e2d1c8edc2ea28922d60f3ce3e534a784622cd1
Original change: https://android-review.googlesource.com/c/platform/bionic/+/2073947
Change-Id: Id15a4a4e86f6bb05378ec1f775fb07693bd9fbda
Ignore-AOSP-First: this is an automerge
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
(cherry picked from commit 0f46547800)
There are other options here (see the code comment for details), but
this is the least effort/least disruptive for now.
Bug: 228898932, 227498625
Test: treehugger
Change-Id: I33be6fbfc022238de2f1846a69af1e712a9d6391
(cherry picked from commit bb1cc5a82c)
This tests PROT_MTE semantics, so we should disable HWASan.
Test: atest CtsBionicTestCases on flame_hwasan
Bug: 230048274
Bug: 230047253
Bug: 230456730
Change-Id: Ibc59b959d0b8353915629919c5d466a21dbe1c5a
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
If a process is failing due to out of memory, some code calls
android_set_abort_message with a nullptr. Specifically, the libc++
library std::terminate can call do this. In this case, put a
null in the abort message.
Test: Call with nullptr and verify the code does not crash.
Test: Modified crasher to set an abort message and set a null abort
Test: message. Ran both, verified the abort message displays in
Test: first case, and doesn't display in the second case.
Change-Id: Ia9250f47e4537853ce93bbb20b35915a78caa502
There are other options here (see the code comment for details), but
this is the least effort/least disruptive for now.
Bug: http://b/227498625
Test: treehugger
Change-Id: I33be6fbfc022238de2f1846a69af1e712a9d6391
This is important for enabling the error about unsupported TLS
relocations to local symbols. The fast path tends to skip this error,
because it fails during lookup_symbol(). Add a test for this error.
I didn't see a performance regression in the linker_relocation
benchmark.
Bug: http://b/226978634
Test: m bionic-unit-tests
Change-Id: Ibef9bde2973cf8c2d420ecc9e8fe2c69a5097ce2
This is exactly what it is testing for.
Original warning:
bionic/tests/stdio_test.cpp:370:47: error: '%n' specifier not supported on this platform [-Werror,-Wformat]
EXPECT_DEATH(snprintf(buf, sizeof(buf), "a %n b", &i), "%n not allowed on Android");
~^
Test: presubmit
Bug: 219872355
Change-Id: I6e378722b2d681cf64f4cf31ef000bd28203b00d
The kernel MTE mode auto-upgrade feature (see mte_tcf_preferred) allows
silent auto-upgrade of Async MTE mode to Asymm or Sync depending on the
OS settings. Relax the tests to allow either Sync or Async faults when
requesting Async mode, and only Sync faults when requesting Sync.
Also tighten the MTENote test to check that both system allocator and
prctl are off when MTE is disabled.
Bug: 214622342
Test: bionic-unit-tests on fvp with all variations of
/sys/devices/system/cpu/cpu*/mte_tcf_preferred=(async|asymm|sync)
Change-Id: I77a92789d6b330742d00b08c9f0fecc3a6c8fca6
Bug: http://b/218788252
IR verifier too strict for ifunc resolver that accept parameters. This
is only exposed with Thin LTO. The error is:
IFunc resolver has incorrect type
i32 ()* @_Z5hwcapv
Test: mmma GLOBAL_THINLTO=true bionic
Change-Id: Ifed4041ee8557ba1a5eb7a5a82f54b5ca5c79161
Bug: http://b/218788252
Even though a resolver can return any pointer, LLVM IR verifier now
checks that the resolver returns a pointer to the ifunc's function type.
Test: m GLOBAL_THINLTO=true libtest_ifunc_variable_impl.so
Change-Id: I7d87ffcf50bab1d61b01328907e036c51feb6a0f
dup2(2) is a no-op if the new and old fds are equal, but it's pretty
clear that any useful caller in the posix_spawn(3) context wants us to
clear O_CLOEXEC even if we don't actually "move" the fd.
Bug: https://www.austingroupbugs.net/view.php?id=411
Test: treehugger
Change-Id: I5ce1a1f9216df5afd295cc9e35b84527873e9541
Not sure how treehugger missed this, but "growler" followed up pretty
quickly, so that's something...
Bug: http://b/219758263
Test: treehugger
Change-Id: I8e4afa31aee975740d10eb2acec51d2f4f1fa414
We don't want expected crashes showing up in the automated crash
reporting!
Bug: http://b/210932139
Test: treehugger
Change-Id: I6b232f0808cdcd39739f249236177cabc40669b1
Currently, the ELF note parsing in the loader is not permissive. This
patch relaxes the restrictions on the bits of the ELF note that could be
extended in the future.
This may allow more MTE options in apexes. If we add some extra metadata
bit (say, in bit 5) in the future, and then build MTE into every apex,
we don't want it to crash on Android 13 devices (we'd much rather it
just be a no-op).
Remove the (unused anywhere) NT_MEMTAG_DEFAULT and call it
NT_MEMTAG_NONE.
And finally, make the tests work on bionic-unit-tests-static. We
previously didn't deploy the test binaries, so add them as a data
dependency.
Bug: N/A
Test: atest bionic-unit-tests-static
Change-Id: I13530faad55c719c6eb848297f8ce378e18afbfc
musl doesn't have fortify, and is missing the *_chk symbols to allow
the tests to compile.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I9a1d2dfe19db219cd2c5a6dc39cb5d08ed0e4369
Musl doesn't provide the resolv b64_* functions, but adb uses them.
Export them from bionic.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I37837e6179a15754d4cbd89e67649df9dea9d9f1
Musl doesn't provide the execinfo function. Export the from bionic.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I0361b84b0160d419cd857f5bb1314a58d0a69234
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
Fix references to symbols that don't exist in musl in the bionic
benchmarks, and disable the header tests for musl.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I6b1964afa4a7b6e6a4812e9f2605fcfc2fae9691
The first time should_trace() returns true, bionic_trace_begin() calls
open() on trace_marker.
The problem is that open() can call bionic_trace_begin(). We've observed
this happening, for example when:
* fdtrack is enabled. dlopen("libfdtrack.so") can be used to enable
fdtrack on a process.
* ThreadA is busy unwinding inside fdtrack and is holding an fdtrack
internal mutex.
* ThreadB calls bionic_trace_begin() for the first time since the
property "debug.atrace.tags.enableflags" contains ATRACE_TAG_BIONIC.
* ThreadB calls open("/sys/kernel/tracing/trace_marker"). Since fdtrack
is enabled, ThreadB tries to do unwinding as well.
* ThreadB, inside fdtrack's unwinding tries to grab the same mutex that
ThreadA is holding.
* Mutex contention is reported using bionic_systrace, therefore
bionic_trace_begin() is called again on ThreadB.
* ThreadB tries to grab g_lock in bionin_systrace.cpp, but that's
already held by ThreadB itself, earlier on the stack. Therefore
ThreadB is stuck.
I managed to reproduce the above scenario by manually pausing ThreadA
inside unwinding with a debugger and letting ThreadB hitting
bionic_trace_begin() for the first time.
We could avoid using g_lock while calling open() (either by releasing
g_lock and reacquiring it later, or by using atomics), but
bionic_trace_begin() would try to call open() again. In my tests, open()
does not call bionic_trace_begin() a third time, because fdtrack has
reentrancy protection, but there might be another code path inside open
that calls bionic_trace_begin again (it could be racy or only happen in
certain configurations).
This commit fixes the problem by implementing reentrancy protection in
bionic_systrace.
Sample callstack from ThreadA deadlocked before the fix:
```
* frame #0: 0x0000007436db077c libc.so`syscall at syscall.S:41
frame #1: 0x0000007436db0ba0 libc.so`bionic_trace_begin(char const*) [inlined] __futex(ftx=0x000000743737a548, op=<unavailable>, value=2, timeout=0x0000000000000000, bitset=-1) at bionic_futex.h:45:16
frame #2: 0x0000007436db0b8c libc.so`bionic_trace_begin(char const*) [inlined] __futex_wait_ex(ftx=0x000000743737a548, value=2) at bionic_futex.h:66:10
frame #3: 0x0000007436db0b78 libc.so`bionic_trace_begin(char const*) [inlined] Lock::lock(this=0x000000743737a548) at bionic_lock.h:67:7
frame #4: 0x0000007436db0b74 libc.so`bionic_trace_begin(char const*) [inlined] should_trace() at bionic_systrace.cpp:38:10
frame #5: 0x0000007436db0b74 libc.so`bionic_trace_begin(message="Contending for pthread mutex") at bionic_systrace.cpp:59:8
frame #6: 0x0000007436e193e4 libc.so`NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*) [inlined] NonPI::NormalMutexLock(mutex=0x0000007296cae9f0, shared=0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:592:17
frame #7: 0x0000007436e193c8 libc.so`NonPI::MutexLockWithTimeout(mutex=0x0000007296cae9f0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:719:16
frame #8: 0x0000007436e1912c libc.so`::pthread_mutex_lock(mutex_interface=<unavailable>) at pthread_mutex.cpp:839:12 [artificial]
frame #9: 0x00000071a4e5b290 libfdtrack.so`std::__1::mutex::lock() [inlined] std::__1::__libcpp_mutex_lock(__m=<unavailable>) at __threading_support:256:10
frame #10: 0x00000071a4e5b28c libfdtrack.so`std::__1::mutex::lock(this=<unavailable>) at mutex.cpp:31:14
frame #11: 0x00000071a4e32634 libfdtrack.so`unwindstack::Elf::Step(unsigned long, unwindstack::Regs*, unwindstack::Memory*, bool*, bool*) [inlined] std::__1::lock_guard<std::__1::mutex>::lock_guard(__m=0x0000007296cae9f0) at __mutex_base:104:27
frame #12: 0x00000071a4e32618 libfdtrack.so`unwindstack::Elf::Step(this=0x0000007296cae9c0, rel_pc=66116, regs=0x0000007266ca0470, process_memory=0x0000007246caa130, finished=0x0000007ff910efb4, is_signal_frame=0x0000007ff910efb0) at Elf.cpp:206:31
frame #13: 0x00000071a4e2b3b0 libfdtrack.so`unwindstack::LocalUnwinder::Unwind(this=0x00000071a4ea1528, frame_info=<unavailable>, max_frames=34) at LocalUnwinder.cpp:102:22
frame #14: 0x00000071a4e2a3ec libfdtrack.so`fd_hook(event=<unavailable>) at fdtrack.cpp:119:18
frame #15: 0x0000007436dbf684 libc.so`::__open_2(pathname=<unavailable>, flags=<unavailable>) at open.cpp:72:10
frame #16: 0x0000007436db0a04 libc.so`bionic_trace_begin(char const*) [inlined] open(pathname=<unavailable>, flags=524289) at fcntl.h:63:12
frame #17: 0x0000007436db09f0 libc.so`bionic_trace_begin(char const*) [inlined] get_trace_marker_fd() at bionic_systrace.cpp:49:25
frame #18: 0x0000007436db09c0 libc.so`bionic_trace_begin(message="pthread_create") at bionic_systrace.cpp:63:25
```
Bug: 213642769
Change-Id: I10d331859045cb4a8609b007f5c6cf2577ff44df
Update the path to the helper binary, and run the test on non-MTE
hardware with the expectation that the bug is not detected.
Test: bionic-unit-tests
Bug: none
Change-Id: I34eb4dc46d0bacd83824d307398f7891d4806686
This was probably the least worst choice at the time, but we have toybox
readelf now, which is a much lighter-weight dependency (that we already
have for some other tests).
This is also one less use of the *renderscript* LLVM, which we'll be
wanting to finally delete soon.
Test: treehugger
Change-Id: I0e05b8f139ec6e6a425b575368f3d514b8b1cc64
It's not clear this was ever needed, it doesn't seem to make any
difference now, and these are the defaults for the obsolete renderscript
LLVM anyway, so... yeah.
This was noticed because it was causing some of our tests to be built as
C++11 rather than [the current default of] C++17.
Test: treehugger
Change-Id: I7d72b3fd58e9cf9a02048b0298eee845d19307f7
clang is smart enough to notice a variable is set but not used,
but these variable are used for testing purposes. Mark one as
unused, and convert the other to a DoNotOptimize.
Bug: 197240255
Test: Compiles without warnings.
Test: Ran unit tests on coral hwasan build.
Change-Id: Ibc873e477355a702579e5a680780c77db0c58046
It's possible for the main thread to leave the RunTimedTest
function before the waiting thread has had a chance to call e.g.
pthread_cond_timedwait(). In this case, pthread_cond_timedwait()
will access the local variable ts after its lifetime has ended. Fix
the bug by making ts a field of pthread_CondWakeupTest instead. The
lifetime of pthread_CondWakeupTest is tied to that of the waiting
thread via the pthread_join() call.
Found with HWASan + uaccess logging.
Change-Id: Iefe8deb30a367dc518013d741c425b041596b0d3
LLD supports `-z global`, unlike ld.gold, which this was previously a
workaround for.
Test: mm in test dir
Change-Id: I1f621c329accfb31912a19544e34447aff0dfa28
Explicitly test an invalid 5-byte UTF-8 sequence with mbrtoc16(3); the
fact that we weren't testing this was shown by coverage data.
Merge the surrogate pair tests in with their fewer-byte siblings to make
it clearer to a human reader that we've covered both cases.
Clear errno to make assertions about errno more convincing.
Test: treehugger
Change-Id: I485a48cc141f3e52058e2138326f3134d41b2243
This came up with POSIX recently. Doesn't seem like it matters since
everyone's had this wrong for 40 years, but "meh" --- it's a trivial
fix, and it's strictly correct even if nobody needs this, so let's just
do it...
(Geoff Clare pointed out that my app compat concern "what if someone's
relying on this bug to pass flags to the shell?" isn't relevant because
while you can indeed do that, you then can't pass a command!)
Bug: https://austingroupbugs.net/view.php?id=1440
Test: treehugger
Change-Id: I64f6440da55e2dc29d0136ee62007197d2f00d46
This is a KI: https://bugs.llvm.org/show_bug.cgi?id=46488
Bug: 203737712
Test: m GLOBAL_THINLTO=true bionic-unit-tests-static
Change-Id: I950a85f9676136299fc994a800d32e20bf12a8dd
They're in glibc, though not in musl.
Also add basic doc comments to the whole of <sys/uio.h>.
Bug: http://b/203002492
Test: treehugger
Change-Id: Ic607f7f349e5b7c9bf66c25b7bd68f827da530d6
The allocator for the native bridge is not necessarily going to
allocate the slack data.
Bug: 202428612
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
(cherry picked from commit 7c0ce86a00)
* -Wstatic-in-inline found in
libm/upstream-freebsd/lib/msun/src/s_lround.c
Test: mm in bionic/tests
Bug: 201432564
Bug: 202752322
Change-Id: I4d506fa539ab0de939d85924a5fd9a61644e4fb0
Use cc_genrules to create the dlext test zips needed by the bionic
tests. The genrules aren't visible to Make, and so don't work with
the `required` property. Move all of the dependencies to `data_bins`,
`data_libs` or `data` for helper binaries, shared libraries or
genrule zip files respectively. The `data*` properties copy the
files into the same directory as a test, respecting the
`bionic-loader-test-libs` relative path specified by each, but
does not put each helper binary in its own subdirectory, so update
the paths in each of the tests.
Bug: 200872604
Test: atest CtsBionicTestCases
Test: atest bionic-unit-tests
Test: cts-tradefed run commandAndExit cts -m CtsBionicTestCases
Test: adb push $OUT/data/nativetest/bionic-unit-tests /data/nativetest/ && adb shell /data/nativetest/bionic-unit-tests/bionic-unit-tests
Change-Id: Ic4257cb4104ff558326df2363730acd20464b051
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
