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
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
Musl doesn't define __NR_clock_gettime and __NR_gettimeofday on
32-bit architectures, #define them to __NR_clock_gettime32 and
__NR_gettimeofday_time32 respectively.
Bug: 190084016
Test: m USE_HOST_MUSL=true bionic-unit-tests-glibc
Change-Id: Iec9ba776a94639a4b6a3ad42f18dfdb0e3580f02
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
Work around the incompatibility between libc++ and !_GNU_SOURCE
by defining a wrapper function around the posix strerror_r in
a file that does not include any libc++ or gtest headers.
Test: bionic-unit-tests-glibc
Change-Id: I6b097079777b5dcd802e295cc566964fe1c01382
The posix spec says strerror_r returns a positive error number, not
-1 and set errno.
Test: bionic-unit-tests-static
Change-Id: I6a12d50d046f9caac299bf3bff63e6c9496c1b6f
Do not assume that tests start with Sync MTE; check the initial setting
and change test logic as appropriate.
Bug: 192480262
Test: bionic-unit-tests with MEMTAG_OPTIONS=(off|sync|async)
Merged-In: Id80301e6426af16f89bd80a7a7ab127b6fd60425
Change-Id: Id80301e6426af16f89bd80a7a7ab127b6fd60425
(cherry picked from commit 53df1f3772)
Do not assume that tests start with Sync MTE; check the initial setting
and change test logic as appropriate.
Bug: 192480262
Test: bionic-unit-tests with MEMTAG_OPTIONS=(off|sync|async)
Change-Id: Id80301e6426af16f89bd80a7a7ab127b6fd60425
We know game developers (and the Games SDK) look at this stuff, so make
a bit more of an effort to ensure it's not completely broken.
Test: treehugger
Change-Id: I20b1c167faa1d9f4f39a94a723dabb848ce34269
This function doesn't return, but it does appear in stack traces. Avoid
using return PAC in this function because we may end up resetting IA,
which may confuse unwinders due to mismatching keys.
Bug: 189808795
Change-Id: I953da9078acd1d43eb7a47fb11f75caa0099fa12
Merged-In: I953da9078acd1d43eb7a47fb11f75caa0099fa12
This function doesn't return, but it does appear in stack traces. Avoid
using return PAC in this function because we may end up resetting IA,
which may confuse unwinders due to mismatching keys.
Bug: 189808795
Change-Id: I953da9078acd1d43eb7a47fb11f75caa0099fa12
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
The LD_CONFIG_FILE test needs to match how Bionic was compiled, and
Bionic only enables LD_CONFIG_FILE for debug builds (i.e. ro.build.type
is "user"). ro.debuggable can be forced on without recompiling Bionic.
Bug: http://b/140324381
Bug: http://b/189422994
Test: bionic unit tests
Change-Id: I139059a7f94d15a5447dab292927606a6bcc48ef
(cherry picked from commit 546723b2b8)
The LD_CONFIG_FILE test needs to match how Bionic was compiled, and
Bionic only enables LD_CONFIG_FILE for debug builds (i.e. ro.build.type
is "user"). ro.debuggable can be forced on without recompiling Bionic.
Bug: http://b/140324381
Bug: http://b/189422994
Test: bionic unit tests
Change-Id: I139059a7f94d15a5447dab292927606a6bcc48ef
Turns out that "NSAP" is yet another ISO standard that no-one actually
uses: https://en.wikipedia.org/wiki/NSAP_address
Test: treehugger
Change-Id: I73b4d924a8f4d34e3e2f2da00d0d5529db8e97d1
The test aims to check that the time obtained the VDSO is the "same"
as that obtained via the system call. Unfortunately, time progresses.
Any check involving some fixed tolerance will have some non-zero
probability of failure.
We can instead check that a VDSO time value lies between two system
call times.
Bug: 184819133
Change-Id: Idb9c17b9f612613f6e18a56ee0f256971ddbdf1f
Signed-off-by: Giuliano Procida <gprocida@google.com>
Also delete some fdsan code that attempts to check for the post-fork
state, but never will, because we update the cached pid upon fork.
Bug: http://b/174542867
Test: /data/nativetest64/bionic-unit-tests/bionic-unit-tests
Test: treehugger
Change-Id: I9b748dac9de9b4c741897d93e64d31737e52bf8e
The sleep(3) / clock(3) test is sensitive to outliers in the
distribution of CPU consumed by the sleep system call.
This changes the measured quantity to be the mean over 5 samples and
sets the threshold to 10ms.
Bug: 184727758
Change-Id: I20df3b620a5fbf4e58a3ca67306370351ac01d0c
Test: treehugger
Signed-off-by: Giuliano Procida <gprocida@google.com>
arm64 was already being careful, but x86/x86-64 and 32-bit ARM could be
caught by a signal in a state where the stack pointer was mangled.
For 32-bit ARM I've taken care with the link register too, to avoid
potential issues with unwinding.
Bug: http://b/152210274
Test: treehugger
Change-Id: I1ce285b017a633c732dbe04743368f4cae27af85
