That was place where APK update mechanism placed tzdata file. Now
the mechanism is removed, so no need to look for tzdata there.
Bug: 148144561
Test: atest CtsBionicTestCases
Test: atest BionicTzdbConsistencyTest
Change-Id: I584400a75651cf24a25df74c7007fcd584838395
This file is included in libandroid_support.a, where using new/delete
breaks libc++ tests that assume that libc++ makes no extraneous
new/delete calls.
This CL changes newlocale/duplocale to return NULL on out-of-memory.
Previously, the behavior varied:
- libc.so: aborted using async_safe_fatal
- libandroid_support.a: throws std::bad_alloc
Bug: none
Test: std/input.output/filesystems/class.path/path.member/path.assign/move.pass.cpp
Test: libcxx/localization/locales/locale/locale.types/locale.facet/no_allocation.pass.cpp
Test: std/input.output/filesystems/class.path/path.member/path.construct/move.pass.cpp
Change-Id: I38c772f249f32322afb9402ebeeb4bb65a908b59
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.18
The file bionic/libc/kernel/uapi/linux/android/binder.h had a bug
in the original 5.18 kernel headers. This was fixed upstream, so
add a comment to the structure but leave the incorrect field the
same as the 5.17 kernel headers.
Bug: 234125620
Test: Builds.
Test: All bionic unit tests pass on a coral device.
Test: Able to log in to wembley system.
Change-Id: Ia72cafbe71fd894c599e15aa5334d7bbcbe74778
TZDEFAULT not applicable to bionic as there is no file per time
zone mapping.
Bug: 25413083
Test: CtsLibcoreTestCases
Test: CtsLibcoreOjTestCases
Test: CtsBionicTestCases
Change-Id: Ie489b5b2cda6c6f623f32e5413da77ec5eaa823f
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
Map all stacks (primary, thread, and sigaltstack) as PROT_MTE when the
binary requests it through the ELF note.
For the reference, the note is produced by the following toolchain changes:
https://reviews.llvm.org/D118948https://reviews.llvm.org/D119384https://reviews.llvm.org/D119381
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more tests in a separate change)
Change-Id: I04a4e21c966e7309b47b1f549a2919958d93a872
Add backtrace_size for only backtracing a single size.
Add backtrace_min_size to set the minimum value of size to backtrace.
Add backtrace_max_size to set the maximum value of size to backtrace.
Documented the new options.
Test: New unit test pass.
Change-Id: I1a773737910cd4bc2af9546547b3a2740bbcb22b
Modify the tests that require a single filename, to use a filename
that has the pid as part of the name. This allows multiple different
versions of the test to run on the same machine, and allows
each test to be run at the same time.
Test: Ran unit tests on device.
Test: Ran the unit tests 100 times, no failures.
Change-Id: Ia38483049e7b66bd3da824bcd484c03e46f85280
The new object incorporates all Android specific knowledge into
a single place and makes everything simpler.
Fixed a bug where if backtrace_full was enabled, the AddBacktrace
function would always set the size to the maximum number
of frames instead of the actual number of frames.
Added a new smoke system tests for backtrace_full.
Modified the smoke test to do a malloc/free, so it's really
a smoke test.
Bug: 232575330
Test: Unit tests pass on device.
Test: Verify the full backtrace actually produces valid backtraces.
Test: Run bionic-unit-tests with backtrace_full enabled.
Test: Run bionic-benchmarks --benchmark_filter=stdlib_malloc_free_decay1/512
Change-Id: I23128a73a8691007e1c7f69e0c99bb4dcd713db8
The new option is named check_unreachable_on_signal. It is meant
to duplicate dumpsys meminfo --unreachable <PID> for non-java
processes. When enabled, a user can send a signal to a process
which will trigger the unreachable check on the next allocation
call.
Added new unit tests.
Test: New unit tests pass.
Test: Enabled for the entire system, then dumped on the netd
Test: process and also system_server.
Change-Id: I73561b408a947a11ce21a211b065d59fcc39097b
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
The libmemunreachable library looks through memory to determine
if pointers are leaked. Unfortunately, the malloc debug code
stores the original pointer in data structures, so it looks like
pointers are still in use. The fix is to mangle the pointers
stored in memory so that it doesn't trick the library into thinking
they are live.
Test: All unit/system tests pass.
Test: Ran libmemunreachable and verified leaks show up.
Change-Id: Ic40a0a5ae73857cde936fd76895d88829686a643
We've had complaints about ubsan issues for years, but never got to the
bottom of them, or saw them ourselves in testing. For some reason (still
not understood) we've started to see this ourselves in T and downstream
branches. So for now, let's just punch that extra hole.
Longer term, ubsan should stop needing any of this, so once
https://reviews.llvm.org/D124212 is in an LTS NDK, we should be able to
get rid of this _and_ the existing sanitizer-related holes.
Bug: https://github.com/android/ndk/issues/1298
Bug: http://b/229989971
Test: treehugger
Change-Id: Id42cb29c4e943c0080c0d34ce4e5d6d1b32da9e8
Linux kernel's close_range() system call (currently) allows:
close() unshare() fcntl(F_SETFD, FD_CLOEXEC)
to be performed on ranges of fds.
All 3 of these are already allowed by seccomp bpf:
as such this doesn't allow you to do anything you can't already do.
We can't add close_range() properly to bionic because we'd need to
fiddle about with ltp and it's too late to add new T API anyway,
so let's just make the direct syscall() call.
We'll add proper support in U.
See also:
https://man7.org/linux/man-pages/man2/close_range.2.html
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I85586d544fc23bed6aee59f00bdb79ee7a8150d1
This value was changed from 64 to 32, but it really should not
have gone down. So fixing back to 64 manually, and then the
next kernel header update should remove the comment but leave
the value unchanged.
Bug: 228783882
Test: Compiles.
Change-Id: I2d81d7bc76fcaa905dce0abb094d61d02c481a5e
This new posix_spawn attribute flag marks all file descriptors
(except stdin/out/err) as close-on-exec before executing any user
registered file actions (posix_spawn_file_actions_addopen/adddup2).
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If458100d6a253a9b0348d4e93a9a610225f89615
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
Two edge cases were found in aosp/2038947:
1. realloc(p, 0) == free() and returns nullptr. Previously, we just
returned a new pointer.
2. If the malloc() part of realloc() fails (e.g. when the size of the
allocation is 1 << 56), then the old memory shouldn't be destroyed.
Bug: N/A
Test: Covered using atest bionic-unit-tests using aosp/2038947.
Change-Id: Ibafc752787129922a1e0323ffa14221d6a14f108
This is required because virtualization_service use
libtombstoned_client_rust which has transitive dependency on
libasync_safe
Test: atest MicrodroidHostTestCases
Bug: 202153827
Change-Id: I9e670d02995f9ed9e67791aaecb300b6bfdbdb03
Clang has its own limits.h which is ahead of ours on the inclusion
path. This header uses include_next to include our header, but only
in hosted mode. This means that in freestanding mode we don't get our
limits.h macro definitions, including LONG_BIT. This ends up causing
our signal.h to produce errors when included in freestanding mode on
32-bit platforms.
Fix the errors by replacing usage of LONG_BIT with (8 * sizeof(long))
in the signal headers.
Change-Id: I18ec7b6876d5f862beae09f0c011128eef97c869
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.17
Test: Boots on a flame and all bionic unit tests pass.
Change-Id: I7057d7308241f3acfa600597d287994c39ababbc
Revert submission 1954983-master-I3030c47be9d02a27505bd4775c1982a20755758c
Reason for revert: PAC has shipped with S, and we're going with app compat outreach rather than regressing security.
Reverted Changes:
I3030c47be:Disable pointer authentication in app processes.
I3030c47be:Disable pointer authentication in app processes.
Change-Id: I8761f08ddbd9077ff98b1a9a0c323de968792778
Modify libfdtrack to use the normal Unwinder object. In addition,
update the libfdtrack so that it doesn't record frames in
libfdtrack.so rather than skipping frames it thinks will be in
the library.
Modify the malloc debug code to use the normal Unwinder object.
Bug: 120606663
Test: All unit tests pass.
Change-Id: I3c9612dd10e62389e6219e68045ee87f7b2625f5
The wrap.<APP> property was broken in Android 12, so provide documentation
about how to workaround it.
Test: NA
Change-Id: I98fdc5801997492442802e1295fb6969f9190e1c
I removed the bionic/scudo directory a while ago, but I must have
missed removing the subdirs from the Android.bp file.
Test: Builds.
Change-Id: I3e2a1f42b91273a566e587e923c7c3889a71ed17
The clang prebuilts now provide a single module with per-architecture
variants instead of a module per architecture.
Bug: 220019988
Test: m checkbuild
Ignore-AOSP-First: topic contains vendor projects
Change-Id: I079f36f94b13e06d59a16cf665b65db76084021a
Merged-In: I079f36f94b13e06d59a16cf665b65db76084021a
Add the bionic NOTICE file to cover the headers included in the
musl sysroot.
Bug: 190084016
Test: examine libc_musl_sysroot.zip
Change-Id: I2b5e1b89e997ac370983e5959a83f09cdcc240e8
Bug: http://b/197147102
versioner in aosp/1997532 is built with clang-r445002 and understands
the new attribute.
Test: mmma bionic
Change-Id: Ia3e3c3840e6013446d2679587b72011aff8c50eb
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
For the perf profiling signal handler to succeed in opening
/proc/self/mem, the process needs to be marked as dumpable in posix
terms. This patch addresses a scenario since Android S where the process
is considered profileable, but is not dumpable on "user" builds. The
solution is to mark the process as dumpable while opening the procfs
descriptors, restoring the original value afterwards. This is the same
approach as the heapprofd heap profiler, which performs the override
within the loaded client library [1].
The particular scenario being addressed is:
* user build
* app does not explicitly opt into being profiled by shell
* app does not explicitly opt out of all profiling
In this case, the app is considered profileable by the platform (but NOT
shell). Therefore ActivityThread marks the process as profileable [2],
but the zygote keeps the process as undumpable as it considers the
profileability from the shell domain [3]. We could change the logic in
the zygote to leave such processes in the dumpable state, but the
override within the signal handler is considered to be more contained as
the dumpability is only needed temporarily.
This override would also apply for any non-dumpable native services that
are signalled for profiling, which is also desireable for profiling
coverage.
This change does not elide any of the existing profileability
checks by the signal handler's preamble and the profiler itself.
[1]
https://cs.android.com/android/platform/superproject/+/master:external/perfetto/src/profiling/memory/client.cc;l=184;drc=78cd82ba31233ce810618e07d349fd34efdb861d
[2]
https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/ActivityThread.java;l=6610;drc=de9cf3392d7872c2bee69b65a614e77bb166b26e
[3]
https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/jni/com_android_internal_os_Zygote.cpp;l=1680;drc=master
Tested: clock app on barbet-user succeeds in opening the procfs
descriptors within the signal handler.
Tested: systemwide profiling on sargo-userdebug works as before.
Bug: 196810669
BYPASS_INCLUSIVE_LANGUAGE_REASON=referencing the name of a cmdline utility
Change-Id: Id621d4312418ff0736c97065e9ee577ff67f40da
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
The bp2build build is failing with:
ERROR: /buildbot/src/android/master/out/soong/workspace/bionic/libc/BUILD.bazel:3187:8: Label '//bionic/libc:execinfo/include/execinfo.h' is duplicated in the 'srcs' attribute of rule 'libc_musl_sysroot_bionic_headers'
ERROR: /buildbot/src/android/master/out/soong/workspace/bionic/libc/BUILD.bazel:3187:8: Label '//bionic/libc:kernel/android/uapi/linux/compiler.h' is duplicated in the 'srcs' attribute of rule 'libc_musl_sysroot_bionic_headers'
ERROR: /buildbot/src/android/master/out/soong/workspace/bionic/libc/BUILD.bazel:3187:8: Label '//bionic/libc:b64/include/bionic/b64.h' is duplicated in the 'srcs' attribute of rule 'libc_musl_sysroot_bionic_headers'
ERROR: /buildbot/src/android/master/out/soong/workspace/bionic/libc/BUILD.bazel:3187:8: Label '//bionic/libc:kernel/uapi/linux/capability.h' is duplicated in the 'srcs' attribute of rule 'libc_musl_sysroot_bionic_headers'
ERROR: /buildbot/src/android/master/out/soong/workspace/bionic/libc/BUILD.bazel:3187:8: Label '//bionic/libc:kernel/android/scsi/scsi/scsi.h' is duplicated in the 'srcs' attribute of rule 'libc_musl_sysroot_bionic_headers'
Rewrite the genrule to avoid referring to the same header twice by
using the NOTICE file as a known location in the bionic/libc directory.
Bug: 190084016
Bug: 218405924
Test: libc_musl_sysroot.zip has same contents
Change-Id: Id1a0484a3ed623bcc03b015d02eef19bbb31c06a
Normally, platform-specific note types in the toolchain are prefixed
with the platform name. Because we're exposing the NT_TYPE_MEMTAG and
synthesizing the note in the toolchain in an upcoming patch
(https://reviews.llvm.org/D118948), it's been requested that we change
the name to include the platform prefix.
While NT_TYPE_IDENT and NT_TYPE_KUSER aren't known about or synthesized
by the toolchain, update those references as well for consistency.
Bug: N/A
Test: Build Android
Change-Id: I7742e4917ae275d59d7984991664ea48028053a1
The musl sysroot needs kernel uapi headers, export them as a zip
file. Also include the execinfo and b64 headers for libexecinfo
and libb64 that are embedded in musl libc.
Bug: 190084016
Test: m USE_HOST_MUSL=true libc_musl_sysroot
Change-Id: Ie862934f6dabd3fc6cbb9f5be01e21549bce51c2
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
Bug: http://b/197147102
Bug: http://b/214080353
With https://reviews.llvm.org/D77491, clang got stricter when issuing
diagnostics regarding builtin functions.
https://reviews.llvm.org/D112024 adds a diagnose_as_builtin attribute
which lets it diagnose builtins even though their signature is slightly
different. This patch adds diagnose_as_builtin attribute as needed.
Versioner is built with an older clang so it doesn't recognize this
attribute. So this is added with a preprocessor check on clang
versions. We can remove the version check once versioner gets updated
shortly after the compiler update.
Test: mmma bionic/tests with clang-r445002
Change-Id: I3d0d63ecdbea0cffe97eb5110e2d9f2a7595a38e
Bug: http://b/214080353
The wrong alignment to aligned_alloc() is deliberate. Silence the
warning around the test.
Test: build with clang-r445002
Change-Id: I73bad7775423c908c2bbe1c550e8ce5aeede129d
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
Unfortunately we have discovered that some applications in the wild
are using PAC instructions incorrectly. To keep those applications
working on PAC enabled devices, disable PAC in application processes
for now.
Bug: 212660282
Change-Id: I3030c47be9d02a27505bd4775c1982a20755758c
This was pretty broken. I think anything using this was being given
always-available annotations for everything but 32-bit x86? Treehugger
should complain loudly if this was actually impacting anything though.
I suspect not since the only user of this mode is mainline which
doesn't target far back enough to have arch-specific introduction
guards.
Test: treehugger
Bug: None
Change-Id: I64e96a89d83e64512e661e88915c48a091198992
Definitions for these are provided in libandroid_support for API
levels that do not expose this in the stubs. For the rare cases where
libandroid_support is not being used this will result in a lower
quality diagnostic (undefined reference instead of "not available
until API 21"), but other fixes would also have that behavior because
the libandroid_support headers are *always* available, even if
libandroid_support won't be linked.
Test: Reverted xfailed tests for #1108 and reran tests with this
Bug: https://github.com/android/ndk/issues/1108
Change-Id: I371f5b9d7caeef8dc7c80f2f6d11280ecba119c9
When we added the fast path for the common case of ASCII, we forgot to
remove the now-dead code that handled the 1-byte case later in these
functions. This was obvious from the code coverage data.
Note that the 16-bit variants are unaffected because they're implemented
as calls to the 32-bit variants with extra range checks/surrogate
handling surrounding the call.
Test: treehugger
Change-Id: Ibd40f823519acb9aae8037bdeb3f9c5e36b9d9a6
A decent chunk of the logcat profile is spent formatting the timestamps
for each line, and most of that time was going to snprintf(3). We should
find all the places that could benefit from a lighter-weight "format an
integer" and share something between them, but this is easy for now.
Before:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
BM_time_strftime 781 ns 775 ns 893102
After:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
BM_time_strftime 149 ns 147 ns 4750782
Much of the remaining time is in tzset() which seems unfortunate.
Test: treehugger
Change-Id: Ie0f7ee462ff1b1abea6f87d4a9a996d768e51056
clang was getting in the way of a strftime(3) optimization, and smaller
hammers weren't working, and this seems like the right choice for libc
anyway? If we have code that can usefully be optimized, we should do it
in the source. In general, though, no libc/libm author should be
ignorant of memset(3) or memcpy(3), and would have used it themselves if
it made sense. (And the compiler isn't using profiling data or anything;
it's just always assuming it should use the functions, and doesn't
consider whether the cost of the calls can be amortized or not.)
Test: treehugger
Change-Id: Ia7e22623e47bfbfcfe46c1af0d95ef7e8669c0f6
The implementation of FUSE BPF requires the FUSE daemon to access BPF
functionalities, i.e., to get the fd of a pinned BPF prog and to update
maps.
In Android the FUSE daemon is part of MediaProvider which, belonging to
the apps domain, can only access the subset of syscalls allowed by
seccomp, of which bpf() is currently blocked.
This patch removes this limitation by adding the bpf() syscall to the
allowed seccomp syscalls.
Allowing the bpf() syscall is safe as its usage is still gated by
selinux and regular apps are not allowed to use it.
Bug: 202785178
Test: m
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I5887e8d22906c386307e54d3131c679fee0d9f26
We could remove this line, but it seems reasonable to leave it in for
clarification/safety, especially if it's moved after the common success
case?
Test: treehugger
Change-Id: I5f7e0da8397f80018e6d55321b26371790087f5c
Mbstowcs and wcstombs cannot get correct return value when called in the environment below api 21, and need to raise the API level to solve the problem.
Test: None
fix bug 1108 https://github.com/android/ndk/issues/1108
Change-Id: Iabcf1bff0be087288646687732ef68870630b48a
"nonplat" was renamed to "vendor" in Android Pie, but was retained
here for Treble compatibility.
We're now outside of the compatbility window for these devices so
it can safely be removed.
Test: build boot cuttlefish device. adb remount, modify
/system/etc/selinux/plat_sepolicy_and_mapping.sha256 to force
on-device policy compilation. reboot. Verify that device boots
without new selinux denials.
Change-Id: I663a524670120ee19dfe785aa5f89b3981bdd378
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
Clang cannot build ifunc with LTO. This is a KI: https://bugs.llvm.org/show_bug.cgi?id=46488
Move the LTO: never down to libc itself, so that we can have LTO for the
rest of linker.
Test: m GLOBAL_THINLTO=true linker
Change-Id: I483fc3944e340638a664fb390279e211c2ae224b
The native bridge libc.so is overridden by
//frameworks/libs/native_bridge_support/libc:libc, mark it
installable: false to avoid a collision in the install rules.
Allows removing BUILD_BROKEN_DUP_RULES from cuttlefish builds.
Relands I5379aa9595a714efdbe1ddc1ff4f65bb45fc67e8 with a fix to
only apply to the shared variant.
Bug: 204136549
Test: m checkbuild
Change-Id: I84abb577e3bb924d39a369670d0b2dbfac45bbc4
The native bridge libc.so is overridden by
//frameworks/libs/native_bridge_support/libc:libc, mark it
installable: false to avoid a collision in the install rules.
Allows removing BUILD_BROKEN_DUP_RULES from cuttlefish builds.
Bug: 204136549
Test: m checkbuild
Change-Id: I5379aa9595a714efdbe1ddc1ff4f65bb45fc67e8
This saves a couple of syscalls in the common case, and also lets static
binaries run in a chroot without /dev/null as long as
stdin/stdout/stderr are actually connected to something (which the
toybox maintainer tried to do).
Test: manual with strace
Change-Id: Ic9a28896a07304a3bd428acfd9ddca9d22015f6e
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
In the following scenario:
* Heapprofd wants to profile a process.
* The process receives the heapprofd signal, so it sets up the ephemeral
hooks.
* The process does not perform any allocation, so the proper heapprofd
hook is never installed.
* Heapprofd terminates.
* Now heapprofd wants to start a new profiling session.
* The process receives the heapprofd signal (again).
In the signal handler, no action is needed at this point. The ephemeral
hooks are already setup, so, at the next malloc, the proper heapprofd
hooks will be installed.
Before this commit, the code logged an error message, but still worked
correctly.
This commit basically just skips the error_log below.
Example of the error message that is now suppressed:
```
process: heapprofd: failed to transition kInitialState ->
kInstallingEphemeralHook. current state (possible race): 2
```
Tested by:
* Running a process that calls malloc on input from stdin.
* (Optional, tested both cases) Enable GWP-Asan by calling
`android_mallopt(M_INITIALIZE_GWP_ASAN, ...`. The call will return
success.
* Attaching heapprofd:
```
external/perfetto/tools/heap_profile -i 1 -p `adb shell pidof <...>`
```
* Detaching heapprofd (CTRL-C). The trace will be empty.
* (If not enabled before) Enabling GWP-Asan. The call will fail (because
GWP-Asan detects heapprofd hooks).
* Reattaching heapprofd.
* Triggering some malloc()s in the process. The error log from above
will not appear in `adb logcat`.
* Detaching heapprofd (CTRL-C). The trace will NOT be empty.
Bug: 192258849
Change-Id: I01699b10ecd19e52e1e77f83fcca955ebd885942
Strictly this still isn't quite the same, because they won't actually be
profiled, but at least they won't *crash* now if they're sent a
profiling signal.
Bug: http://b/201497662
Test: treehugger
Change-Id: I0728492eed77584cd850d28897056996387e6671
When calling write on an FD for trace_marker, it is expected that the
pointer passed will be paged into memory. If this isn't the case, the
kernel will ignore the string passed and instead write "<faulted>" to
the ring buffer.
For end events, we were passing a constant string which resides in
the rodata section of the ELF file. If this section is paged out, we
end up not closing atrace stacks correctly leading to very broken traces.
For even more context, see the associated bug.
Fix this issue by reading the constant string to the stack first
which should mean the string is always paged in.
Bug: 197620214
Change-Id: I6a444ac6fe83a6a9fb696c5621e392eca7e9437a
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
...since the implementation is BSD. I missed this in the original code
review (and the presubmit hooks were skipped, so the machines didn't
notice).
Test: N/A
Change-Id: Ia9fe067c68b3ab8045d3f5dfe256f3200f102fbf
musl libc doesn't provide fts, but elfutils and libabigail need it.
Export bionic's fts as a staic library that can be linked into elfutils
and libabigail when compiling against musl.
fts uses recallocarray, which musl doesn't provide, so also include
recallocarray.c in libfts.a.
Requires minor tweaks to fts.c and a wrapper around fts.h to make them
compatible with musl, primarily by providing local definitions of macros
provided in bionic's sys/cdefs.h.
Bug: 190084016
Test: m libfts
Change-Id: Ifac9a59e7504c0c1f5f8a3a5bd3c19a13980b83c
fts.c is from openbsd and has compatibility macros to make it compile
as part of bionic. Move it into libc_openbsd_ndk where it will
get the workarounds from -include openbsd-compat.h instead.
Test: m libc
Change-Id: I213d423af8f010e39460b611e902acbf3561ae7a
I accidentally made the tests run MAX_RETRIES times instead of
running once when passing, and at most MAX_RETRIES when the
test fails. Also, add a bit of randomness to the usleep to try and
avoid tests syncing up on failures.
Bug: 193898572
Test: Ran unit tests and verified that a pass doesn't result in another run.
Test: Ran three copies of the unit tests at the same time to verify that
Test: there isn't a flaky test failure.
Change-Id: I8b8d3cd05ca7d1e87ce34bf10aeef84f6989fdab
If the DispatchReset fails, the subsequent iteration has the wrong
idea of what the "original" table is, and if a subsequent DispatchReset
succeeds it unhooks them.
Repro in https://r.android.com/1767868.
Bug: 193012939
Bug: 189776979
Change-Id: I30445c053fcb785669f75d9c83056926d850edce
The posix spec says strerror_r returns a positive error number, not
-1 and set errno.
Test: bionic-unit-tests-static
Change-Id: I6a12d50d046f9caac299bf3bff63e6c9496c1b6f
