Remove tests of implementation details rather than the CFI
functionality itself. In particular, CFI is designed to protect against
invalid calls to executable code, whereas heap memory is covered by page
protection.
Bug: http://b/298741930
Test: treehugger
Change-Id: Ib7f8af283b4c0001da8fa80a1b281bdc4c50af51
Hopefully this is totally unambiguous and non-confusing output:
```
Expected equality of these values:
Errno(22)
Which is: EINVAL
Errno((*__errno()))
Which is: ENOSYS
```
Test: treehugger
Change-Id: Iefe6a8a6447e76681c18256d2713e2c527081c75
strerrordesc_np() isn't very useful (being just another name for
strerror()), but strerrorname_np() lets you get "ENOSYS" for ENOSYS,
which will make some of our test assertion messages clearer when we
switch over from strerror().
This also adds `%#m` formatting to all the relevant functions.
Test: treehugger
Change-Id: Icfe07a39a307d591c3f4f2a09d008dc021643062
The close_range() test in particular has been confusing a lot of
partners. I think the sys_epoll_test.cpp idiom is the clearest of the
ones in use, so let's use that everywhere. (I haven't actually touched
the SysV IPC tests, because if we do touch them, _deleting_ them --
since all those syscalls are not allowed on Android -- is probably the
change to be made!)
I'm on the fence about factoring this idiom out into a macro. There
should never be too many of these, and we should probably be removing
them? Is anyone still running the current bionic tests on 4.3 kernels
without membarrier(2), and if they are --- why?!
For now though, I haven't removed any of our existing tests; I've just
moved them over to the sys_epoll_test.cpp style.
Test: treehugger
Change-Id: Ie69a0bb8f416c79957188e187610ff8a3c4d1e8f
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
A clang update enabled -Wreorder-init-list by default. Since it doesn't
provide any benefit to the bionic code, disable the warning.
Test: Builds without warnings.
Change-Id: I5891527ef532b59dc2a02b39a5896112411d21f5
Musl doesn't have the _SC_LEVEL?_?CACHE_SIZE sysconf macros.
Bug: 257334542
Test: m USE_HOST_MUSL=true host-native
Change-Id: I42e65daa9169e129059ddde5eee487ea51e6f143
When used in an ifunc resolver, errno@plt won't be available. This is
the API the rivos folks contributing to glibc are leaning towards, for
the same reason. Hit by the berberis folks because they don't implement
the syscall so they were trying to set errno to ENOSYS.
Tested by looking at the generated assembler, and also disabling the
vdso (since on actual systems, this will go via the vdso).
Test: treehugger
Change-Id: Ie2779110f141f20efe97cb892fbdefd808b5339b
musl already added tcgetwinsize() and tcsetwinsize(), but I didn't
notice.
Trivial single-line inlines added to a header that's already written
that way.
Test: treehugger
Change-Id: Iac95ea6a89f3872025c512f7e61987b81d0aafa7
This is a bit disappointing. I'd not implemented this in the past
because it wasn't available on all platforms, and -- although the
riscv64 implementation was just a cool optimization -- I thought that
the /sys stuff was actually portable, until I ran it on arm64 hardware.
So here we have getauxval() for riscv64, /sys for x86-64, and our best
guess based on ctr_el0 for arm64.
Bug: http://b/294034962
Test: ran tests on the host, an arm64 device, and riscv64 host and qemu
Change-Id: I420b69b976d30668d4d2ac548c4229e2a4eafb20
I've also added doc comments for everything in <sys/epoll.h>.
I've also broken up the old "smoke" test (which was taking 2s on my
riscv64 qemu) to keep the total runtime for all the tests down to 200ms.
Test: treehugger
Change-Id: Icd939af51886fdf21432653a07373c1a0f26e422
Missed this when we added the new C23 binary output to the printf()
family.
Also fix %X to use "0X" instead of "0x" and add missing tests.
Test: used by new LD_SHOW_AUXV functionality
Change-Id: I6623b92acec7daf534536697de0f87352a2653ad
Talking futher to the person doing the glibc risc-v ifunc work, they
clarified that glibc _is_ passing hwcap as the first argument, and the
null pointer is actually the second argument.
https://sourceware.org/pipermail/libc-alpha/2023-August/150967.html
So since our whole purpose here was source compatibility, let's do what
they're actually doing, and let's add some tests. I've also added a test
that __riscv_hwprobe() works from an ifunc resolver because that's one
place where it might well be used. That said, one other thing that came
out of the discussion is that I actually went away and looked at a
sample of top apps to see how many are using ifuncs currently. The
result? Zero. So although this _might_ be interesting long term
(especially if clang gets riscv64 FMV), I think we've done more than we
need to with riscv64 ifuncs for now!
Test: ran locally, both dynamic and static tests
Change-Id: Ie2044d9f4e47c32c00ad381f045c537f4df38b08
This list has diverged between cts/ and bionic/. Instead of having to
maintain the list, let's just make cts/ inherit the one from bionic.
Bug: 296832150
Test: atest bionic-unit-tests CtsBionicTestCases
Change-Id: I271668e83aed239107b9129dfb707f03bae47cfa
Also fix a __has_include() that was copy & pasted without modification
from a different test.
Test: treehugger
Change-Id: Iafceb331a95ec788596ffdad60aa2202b692e589
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
We've had these backward all this time. The relevant quote is in a
code comment in the implementation, but the first call after
completely decoding a code point that requires a surrogate pair should
return the number of bytes decoded by the most recent call, and the
second call should return -3 (if only C had given those some named
constants that might have been more obviously wrong).
Bug: https://issuetracker.google.com/289419882
Test: Fixed the test, tests run against glibc and musl to confirm
Change-Id: Idabf01075b1cad35b604ede8d676d6f0b1dc91e6
Same as in uchar_test.cpp: glibc implements a much older unicode
standard which allows these.
Bug: None
Test: this is a test
Change-Id: Iead5eb01d391be85a7b1a034ea9e7f8828e81cdb
Same as the previous change for the uchar tests: the tests are wrong
to match bionic's wrong implementation. Fix the test to encode the bug
for now while I get the tests into good shape, then I'll be back to
fix the bugs and remove the test differences.
Bug: None
Test: this is a test
Change-Id: I1123660994f755f8bac1f2656f6890d5a43310b3
glibc immediately dereferences the locale passed to all wcsto*_l
functions, even if it won't be used, and even if it's
LC_GLOBAL_LOCALE, which isn't a pointer to valid memory.
Bug: None
Test: this is the test
Change-Id: Ia307cbd6a5c5b4b904c978a03e6d06c1cef6ceed
Change a test to use a signal that does not trigger a tombstone.
Also changed the gwp_asan_integration.DISABLED_assert_gwp_asan_enabled
test to inherit from the SilentDeathTest to prevent tombstones
being generated.
Test: Ran tests and no tombstones generated.
Change-Id: I0f104704829dde692aa515a63dea1c6971278c29
A few death tests are not set to silence tombstones, so fix
all of those occurrences.
Test: Ran all death tests and no tombstones generated.
Change-Id: If2b54b1a3432edbd54076439d40527d966607f70
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
These all appear to be either musl bugs or underspecified corners of
the C standard, so rather than verify the musl behavior I've just
disabled the body of the test for musl.
Now that this is skipped, all the uchar tests are passing for bionic,
glibc, and musl.
Bug: None
Test: None
Change-Id: Icf88ef42e9b750ab45ba76bf8112967b00e72a9f
Doesn't do anything for bionic (which is why this has gone unnoticed),
but it does change the locale for glibc and musl. After this patch,
all these tests pass on glibc. musl is still failing in
uchar.start_state, which I haven't finished investigating.
This should probably be a test fixture so it's harder to forget, but
there are a handful of tests here which don't call setlocale until
part way through the tests, and I'm not certain if that was attempting
to test some non-obvious behavior, or if that was just an accident. I
don't want to change that test behavior before understanding it
better, so this will do for now.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Ib781a41893f021e336e67281070932f41f792318
This one forgot to set its locale, so it was passing on glibc (because
the sequence here wasn't valid in its default locale) and failing on
musl, both for the wrong reasons.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Ic6bcd1836ba23c7010e2cde673a3beca73778021
Musl was treating 0xf0 as a valid character in its default locale. I
didn't dig into whether that was a musl bug or whether it was actually
translating whatever extended ASCII character that was into the
correct code point (tbh I don't know what the rule there is either).
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: I0845fdee9a016ad67ccff3716129ff29f83a63d7
Also actually assign a bool to it. I'd originally written a #define
and apparently forgot to fix the value. I'm a bit surprised that clang
didn't complain.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Iac46bc9c48fd70853d5c447e812e25e617281d2b
While looking at the disassembly for the epoll stuff I noticed that this
expands to quite a lot of code that the compiler can't optimize out for
LP64 (because it doesn't know that the "copy the argument into a local
and then use the local" bit isn't important).
There are two obvious options here. Something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
int signalfd(int fd, const sigset_t* mask, int flags) {
#if defined(__LP64__)
return signalfd64(fd, mask, flags);
#else
SigSetConverter set = {.sigset = *mask};
return signalfd64(fd, &set.sigset64, flags);
#endif
}
```
Or something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
#if defined(__LP64__)
__strong_alias(signalfd, signalfd64);
#else
int signalfd(int fd, const sigset_t* mask, int flags) {
SigSetConverter set = {};
set.sigset = *mask;
return signalfd64(fd, &set.sigset64, flags);
}
#endif
```
The former is slightly more verbose, but seems a bit more obvious, so I
initially went with that. (The former is more verbose in the generated
code too, given that the latter expands to _no_ code, just another symbol
pointing to the same code address.)
Having done that, I realized that slight changes to the interface would
let clang optimize away most/all of the overhead for LP64 with the only
preprocessor hackery being in SigSetConverter itself.
I also pulled out the legacy bsd `int` conversions since they're only
used in two (secret!) functions, so it's clearer to just have a separate
union for them. While doing so, I suppressed those functions for
riscv64, since there's no reason to keep carrying that mistake forward.
posix_spawn() is another simple case that doesn't actually benefit from
SigSetConverter, so I've given that its own anonymous union too.
Test: treehugger
Change-Id: Iaf67486da40d40fc53ec69717c3492ab7ab81ad6
Same as the earlier fix for mbrtoc16. Other implementations support
the older RFC, bionic supports the new one.
Bug: None
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Change-Id: I9e85a9ae53aaaa112a76665063acd2bd856b26cf
glibc and musl both interpreted the spec differently than we did
(better, imo) for the return value of a zero-length conversion. Fix
the test to handle that.
Also converted the test from ASSERT to EXPECT to reduce the number of
builds needed to find failures.
Bug: None
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Change-Id: Id74364040ce3b0e21bacd78f70467053cc8a6058
Also split that case out into a separate test to avoid complicating
the test for the common cases.
Bug: None
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.mbrtoc16"
Change-Id: If7e50f659ad99ee9bab8847fc7320c7bbd629c5d
The obsolete mips header rides again!
The most interesting part of this change is that I've removed the hack
that meant that all system call wrappers starting with `__` defaulted to
being hidden symbols. That's no longer useful given our linker scripts,
and it actively got in the way here because the public libc symbol
actually starts with `__` in glibc, and it would be weird and annoying
for developers if we chose a different name.
Test: strace
Change-Id: I230479787895e8e34f566ade36346a8241eea998
The hidden pointer makes this trickier than the usual incantation, so
leave some copy & paste lying around for anyone trying to work this out.
Test: treehugger
Change-Id: I26e94bf7a74ce3e43de587edc52ab63e36d1d86b
This works (by reading /etc/localtime) on NetBSD, but not on Android
since we have no such file. Fix that by using our equivalent system
property instead.
Also s/time zone/timezone/ in documentation and comments. We've always
been inconsistent about this (as is upstream in code comments and
documentation) but it seems especially odd now we expose a _type_ that
spells it "timezone" to talk of "time zone" even as we're describing
that type and its associated functions.
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: I142995a3ab4deff1073a0aa9e63ce8eac850b93d
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
* Rationale
The question often comes up of how to use multiple time zones in C code.
If you're single-threaded, you can just use setenv() to manipulate $TZ.
toybox does this, for example. But that's not thread-safe in two
distinct ways: firstly, getenv() is not thread-safe with respect to
modifications to the environment (and between the way putenv() is
specified and the existence of environ, it's not obvious how to fully
fix that), and secondly the _caller_ needs to ensure that no other
threads are using tzset() or any function that behaves "as if" tzset()
was called (which is neither easy to determine nor easy to ensure).
This isn't a bigger problem because most of the time the right answer
is to stop pretending that libc is at all suitable for any i18n, and
switch to icu4c instead. (The NDK icu4c headers do not include ucal_*,
so this is not a realistic option for most applications.)
But what if you're somewhere in between? Like the rust chrono library,
for example? What then?
Currently their "least worst" option is to reinvent the entire wheel and
read our tzdata files. Which isn't a great solution for anyone, for
obvious maintainability reasons.
So it's probably time we broke the catch-22 here and joined NetBSD in
offering a less broken API than standard C has for the last 40 years.
Sure, any would-be caller will have to have a separate "is this
Android?" and even "is this API level >= 35?" path, but that will fix
itself sometime in the 2030s when developers can just assume "yes, it
is", whereas if we keep putting off exposing anything, this problem
never gets solved.
(No-one's bothered to try to implement the std::chrono::time_zone
functionality in libc++ yet, but they'll face a similar problem if/when
they do.)
* Implementation
The good news is that tzcode already implements these functions, so
there's relatively little here.
I've chosen not to expose `struct state` because `struct __timezone_t`
makes for clearer error messages, given that compiler diagnostics will
show the underlying type name (`struct __timezone_t*`) rather than the
typedef name (`timezone_t`) that's used in calling code.
I've moved us over to FreeBSD's wcsftime() rather than keep the OpenBSD
one building --- I've long wanted to only have one implementation here,
and FreeBSD is already doing the "convert back and forth, calling the
non-wide function in the middle" dance that I'd hoped to get round to
doing myself someday. This should mean that our strftime() and
wcsftime() behaviors can't easily diverge in future, plus macOS/iOS are
mostly FreeBSD, so any bugs will likely be interoperable with the other
major mobile operating system, so there's something nice for everyone
there!
The FreeBSD wcsftime() implementation includes a wcsftime_l()
implementation, so that's one stub we can remove. The flip side of that
is that it uses mbsrtowcs_l() and wcsrtombs_l() which we didn't
previously have. So expose those as aliases of mbsrtowcs() and
wcsrtombs().
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: Iee1b9d763ead15eef3d2c33666b3403b68940c3c
wfN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to a fastest minimum-width integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to a fastest minimum-width integer type argument with a width of N bits. All fastest minimum-width integer types (7.22.1.3) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: Iaa1f6d87251144de0b763672ca93f23272880ad1
Although the existing annotations were strictly true (see
https://github.com/android/ndk/issues/1888#issuecomment-1581773348 for
the gory details), given the Play Store requirement that 32-bit code
must have a 64-bit version, it's not obviously useful to offer a
function for 32-bit before 64-bit.
Test: treehugger
Change-Id: I8ca11b874c26dfaa632690f510cb5409d95012e9
wN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to an integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to an integer type argument with a width of N bits. All minimum-width integer types (7.22.1.2) and exact-width integer types (7.22.1.1) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: I595fd2ac7bc40d9fb7f1935b39933a6cc068eeff
Discussion of this during my recent minor cleanup convinced me that we
should just remove __RENAME_LDBL. There's no obvious benefit to being
able to build something for 32-bit if you can't build the same code for
64-bit, given that most new hardware (and entire verticals such as Auto)
are 64-bit-only, and the Play Store requires any app with 32-bit code to
also ship 64-bit code.
Test: treehugger
Change-Id: I1c5503b968ca66925d7bd125bd3630c41ec1bfd0
The only remaining differences between vfprintf.cpp and vfwprintf.cpp
after this are the wide/narrow conversions for %c, %m, and %s. I've used
"chars" and "bytes" for the named constants for the directions because
(a) I find -1 and 1 pretty confusing and (b) although "narrow" is the
obvious opposite of "wide", only Windows actually moved to wide
characters, so "narrow" (aka "multibyte", and probably "utf8") is the
default/normal case. Even though C confuses bytes and characters via its
`char` type, "bytes" versus "chars" seems like the appropriate
terminology (and it's what Java/Python use).
Also improve the swprintf tests assertion so failures are readable.
Test: treehugger
Change-Id: Ife8f70f65ec28d96058a7d68df353945524835d2
This reduces the amount of boilerplate for these tests, and ensures that
we have a corresponding swprintf() test for every snprintf() test
(except the handful where it doesn't make sense; we have no FORTIFY for
the wide-character routine, for example).
Test: treehugger
Change-Id: I14091683494bbb414f1a72bddc9835b86ff62526
Jens Gustedt suggested a better implementation last year on the musl
mailing list: https://www.openwall.com/lists/musl/2022/11/19/1
It means the constants are sparse, but in return it means we can add
future constants and they'll be backward compatible. (Sadly you'll need
to be on API level 35 before you can use anything but TIME_UTC.)
I doubt this will ever matter, because everyone should just stick to
clock_gettime()/clock_getres() anyway, and anyone who does have a
legitimate use for timespec_get() and timespec_getres() probably needs
to support non-Linux and so can't use any clocks that aren't in ISO C
anyway. But given that we don't _have_ to paint ourselves into a corner
here, we may as well take the opportunity to not do so.
Test: strace
Change-Id: I293d32fcbcf7f6703564dac0978ae2a10192a482
This is the one openlog() flag that toybox uses. We should probably try
to unify toybox's POSIX logger and Android-specific log at some point,
and this will help.
Also fix our behavior with an empty format string, noticed while adding
tests.
Test: treehugger
Test: adb shell logger -s foo
Change-Id: Ic027e78a460be3db83cc4c6f9946c9efa22be6e1
wfN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to a fastest minimum-width integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to a fastest minimum-width integer type argument with a width of N bits. All fastest minimum-width integer types (7.22.1.3) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: Ida36d5a50af2a46fd04cb5fe039793d8872f9f3b
Although this breaks job control in several shells (including mksh),
this has been broken since the initial commit and no-one's noticed until
now.
Bug: https://github.com/android/ndk/issues/1878
Test: treehugger
Change-Id: Id7c4805965c5e5847db99b57df1af13355adcc22
57b8fc957a
changes the way overflows are tracked: now compiler builtins
are used instead of manual arithmetics. But as int_fast32_t on
64-bit Android takes 8 bytes, new logic behaves differently.
See time_test.cpp changes for more details.
Changes were applied using following commands:
1) Checkout tzcode repo
2) Prepare patches for all tzcode file using
git diff 2022a 2023a -- <file-name> > <file-name-patch>
3) Apply these patches to files in bionic using
patch -p1 <file-name> <file-name-patch>
Bug: 279742606
Test: CtsBionicTestCases
Test: CtsLibcoreTestCases
Test: CtsLibcoreOjTestCases
Test: atest toybox-tests
Change-Id: I7772a90538b8185bdd2f4be6e9d1740c95509d6c
When annotating the netinet directory aosp/2552567, we realize the
argment s for vsnprintf family can be null only if the buffer size is 0.
So we correct them and add some tests to verify our assumption.
Bugs: b/245972273
Test: adb shell
Change-Id: I51063286272be0daee0d7c1453a374b1f5674481
Nothing to see here --- you'll want to keep using POSIX clock_gettime()
and clock_getres() instead. But portable code might use this eventually,
and it's trivial, so let's add it anyway.
(The whole "zero as an error return" precluding the direct use of
Linux's CLOCK_ constants is what really makes this a terrible API ---
we're going to have to add explicit translation any time they add a
new base.)
Test: treehugger
Change-Id: Iddb6cbe67b67b2b10fdd8b5ee654896d23deee47
Someone uploaded --no-verify, and now I'm being asked to change the
NOTICE file. Instead, let's just use the existing BSD header for 2023,
since we've been trying to keep the tests BSD licensed anyway.
Test: treehugger
Change-Id: I4a5b1a50c65bebaaa3015634b67868b3b7a7ce32
Since we need a page-aligned allocation for a thread stack, explicitly
ask for one. (Scudo happens to just give us one anyway for an allocation
this large, but 32-bit jemalloc does not.)
Bug: http://b/277598913
Test: treehugger
(cherry picked from https://android-review.googlesource.com/q/commit:18e335b3da7ae1afd74055cbe7f0d85541863691)
Merged-In: I41eeb6aadb6a22bf5d9619e768e5e0a76617f747
Change-Id: I41eeb6aadb6a22bf5d9619e768e5e0a76617f747
Since we need a page-aligned allocation for a thread stack, explicitly
ask for one. (Scudo happens to just give us one anyway for an allocation
this large, but 32-bit jemalloc does not.)
Bug: http://b/277598913
Test: treehugger
Change-Id: I41eeb6aadb6a22bf5d9619e768e5e0a76617f747
wN: Specifies that a following b, d, i, o, u, x, or X
conversion specifier applies to an integer argument with
a specific width where N is a positive decimal integer with
no leading zeros
Bug: b/271903607
Test: adb shell
Change-Id: I688f6cefeb2e5c8325b007a59935a46f4116ac29
This isn't a very helpful way to say "realpath() failed":
```
bionic/tests/dlfcn_test.cpp:(1006) Failure in test dlfcn.dladdr_libc
Value of: realpath("/system/lib64/" "hwasan/libc.so", libc_realpath) == libc_realpath
Actual: false
Expected: true
```
Bug: http://b/278795547
Test: treehugger
Change-Id: I1078ab4a675b956327f2578086a1a5e7d8a2928b
Contrary to the old comment, POSIX says nothing about whether or not
tmpfile() respects $TMPDIR, and it's significantly more useful on
Android if it does (because there's no shared /tmp that everyone can
write to).
Bug: https://issuetracker.google.com/36991167
Test: treehugger
Change-Id: I3cc45adff167420f100c8ed1c63cba1ea67e9f70
Musl #defines utmp to utmpx, which causes the tests in utmp_test.cpp
to collide with the ones in utmpx_test.cpp. Skip the utmp_test.cpp
when building for musl.
Test: m USE_HOST_MUSL=true
Change-Id: Ie05ddf6e1fd8c3bcc687d2537c19b6ab70ab8d67
This mode instructs the linker to search for libraries in hwasan
subdirectories of all library search paths. This is set up to contain a
hwasan-enabled copy of libc, which is needed for HWASan programs to
operate. There are two ways this mode can be enabled:
* for native binaries, by using the linker_hwasan64 symlink as its
interpreter
* for apps: by setting the LD_HWASAN environment variable in wrap.sh
Bug: 276930343
Change-Id: I0f4117a50091616f26947fbe37a28ee573b97ad0
The recent header nullability additions and the corresponding source
cleanup made me notice that we're missing a couple of actions that most
of the other implementations have. They've also been added to the _next_
revision of POSIX, unchanged except for the removal of the `_np` suffix.
They're trivial to implement, the testing is quite simple too, and
if they're going to be in POSIX soon, having them accessible in older
versions of Android via __RENAME() seems useful. (No-one else has shipped
the POSIX names yet.)
Bug: http://b/152414297
Test: treehugger
Change-Id: I0d2a1e47fbd2e826cff9c45038928aa1b6fcce59
Now <utmpx.h> isn't any more useful on Android than <utmp.h> is, but it
is POSIX, and -- importantly -- we can implement it with just a header
file, so code can use it on every existing API level.
macOS does indeed only have the <utmpx.h> functions (although it does
still have the <utmp.h> header!), so potentially portable code might
want <utmpx.h> on Android. (glibc/musl both have both headers.)
Bug: https://github.com/landley/toybox/pull/213
Test: treehugger
Change-Id: Iaa88167708182009a63e2e1a15f11186b251ed02
While these tests were running, other native processes would get torture GWP-ASan. This can lead to OOMs.
Bug: 273904016
Change-Id: Ia813a73bfc1c379633be022dbf4b7d567069c731
Test: atest bionic-unit-tests (in presubmit)
This test was flaky because there was no synchronization between the end
of the test function scope and the jumper threads, resulting in a racy
use-after-scope when accessing the thread array. Fix it by joining the
threads before leaving the test function scope.
Replace the thread array access, which can race with the store to the
thread array in the main thread, with an access to a pre-initialized
variable, which acts as a kind of enforcement that the threads are done
before leaving the test.
Bug: 227390656
Change-Id: Icfbb0d7cae66c12e5ce31072c34529e3c5fdf563
We don't support running threads on a tagged stack. Untagging SP may
lead to accesses to the stack via a non-SP register, which will be tag
checked, and the check will fail. And indeed that's exactly what the
__bionic_clone function does in its first instruction. Fix the problem by
disabling HWASan and MTE stack tagging on CloneStartRoutine, and remove
the call to untag_address, as it is unnecessary.
Bug: 273807460
Change-Id: I94cc56c816897531c0113c856b54ec41b4aab874
The strerror_buf is way too large, so instead of using a separate
buffer for just this string, reuse the already existing buffer.
Increase the buffer size to cover the maximum errno string.
Add a unit test to verify that none of the errno values are cut off
in the async_safe_format_buffer function when passing %m.
Bug: 274474681
Test: New unit test passes.
Test: Changing the buffer to a small value and verify that the test fails.
Change-Id: I4cb4652709582a8a6b958e12de5d923ec950e6b6
clang-r487747 gets too clever and removes the store, even if it is
declared as volatile. Set optnone to prevent the compiler optimizing out
the store.
Test: atest CtsBionicTestCases
Bug: 271214588
Change-Id: I14a537ecd4657ee3f510ff531313bd9d56f22f47
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
