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
We're going to dereference a null pointer if you pass one instead of a
pointer to a path, but at the moment (because of implementation sharing
between the different file actions) we won't do it until the last
minute, in the child itself. Let's crash as soon as you make the mistake
instead, to make debugging a lot easier.
Test: treehugger
Change-Id: I987d2700ba05b9867a936ebe770224259376633f
Move the "is there a comparator?" check into the sole caller, to match
the "is there a filter?" check. Remove the unnecessary (and unlikely)
pre-sort "is the array empty?" check.
Test: treehugger
Change-Id: I8bd461380420dce4a8bc05ef5fe3511b26347d7c
Use __memcpy_chk assembly to replace the implementation of c functions, which can reduce the use of instructions
Test: llvm-objdump
Change-Id: I5d75601626dc997626f6173d53af301183a64004
Signed-off-by: caowencheng <caowencheng@eswincomputing.com>
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
These are just one-liners, and the _FLOCK() macro seemed to me more
obscure than just inlining it (especially because there are only four
call sites total, so it's not like anyone's going to see that macro very
often).
Also add the missing CHECK_FP() calls. I don't expect this to break
anything, but if it does we can add a target API level check.
Test: treehugger
Change-Id: Ifa1a39d5d9eee46cca783acbe9ec3b3a1e6283d9
The next NDK to take these headers only supports API 21 and later.
Note that this change leaves the _implementation_ of these functions
behind, so that any old apps calling these APIs should continue to work,
you just can't (without declaring the functions yourself) write new ones
that do (and declaring the functions yourself would only work on LP32
anyway, so that's not going to get you very far in 2023).
Test: treehugger
Change-Id: Ie03514e4215b40f6e9feaa6e4bf5df5b16dc8d59
API level 19 is no longer supported by the NDK.
While I'm here, let's remove the duplicated structure defintion (as
we've already done for `struct stat`).
Test: treehugger
Change-Id: I9d8286f9e7ba803f3131b6dcb0486ff1b0f9d5d1
This mode allows an android_mallopt(M_INITIALIZE_GWP_ASAN, ...) to turn
on the recoverable, sampled mode. This is the intended mode for
non-system apps that don't specify the gwpAsanMode in Android U.
Bug: 247012630
Test: Patch the zygote to use this option, launch an app with
gwpAsanMode unspecified, trigger a use-after-free, assert the app uses
the recoverable mode.
Change-Id: I701e10f44b2e2694789cc5ec6f0af4bc0c55b9e4
GWP-ASan's recoverable mode was landed upstream in
https://reviews.llvm.org/D140173.
This mode allows for a use-after-free or a buffer-overflow bug to be
detected by GWP-ASan, a crash report dumped, but then GWP-ASan (through
the preCrashReport() and postCrashReportRecoverableOnly() hooks) will
patch up the memory so that the process can continue, in spite of the
memory safety bug.
This is desirable, as it allows us to consider migrating non-system apps
from opt-in GWP-ASan to opt-out GWP-ASan. The major concern was "if we
make it opt-out, then bad apps will start crashing". If we don't crash,
problem solved :). Obviously, we'll need to do this with an amount of
process sampling to mitigate against the 70KiB memory overhead.
The biggest problem is that the debuggerd signal handler isn't the first
signal handler for apps, it's the sigchain handler inside of libart.
Clearly, the sigchain handler needs to ask us whether the crash is
GWP-ASan's fault, and if so, please patch up the allocator. Because of
linker namespace restrictions, libart can't directly ask the linker
(which is where debuggerd lies), so we provide a proxy function in libc.
Test: Build the platform, run sanitizer-status and various test apps
with recoverable gwp-asan. Assert that it doesn't crash, and we get a
debuggerd report.
Bug: 247012630
Change-Id: I86d5e27a9ca5531c8942e62647fd377c3cd36dfd
It makes sense that callers to getauxval() should have to pay for a
search --- that's exactly what they're asking for. But it seems silly
and unfair for the same to be true of sysconf() --- that's just an
implementation detail. Call getpagesize() directly instead.
Test: treehugger
Change-Id: I327adc55ace73bc6da68c4b34bf829d377bcbd1a
This is a no-op but will be used in upcoming scudo changes that allow to
change the buffer size at process startup time, and as such we will no
longer be able to call __scudo_get_ring_buffer_size in debuggerd.
Bug: 263287052
Change-Id: I18f166fc136ac8314d748eb80a806defcc25c9fd
We still have local differences, but this minimizes (and documents) them.
Bug: http://b/167569813
Test: treehugger
Change-Id: Ib90e6ccc5ec1224e7ee89224a51b87fc48c9931f
Treehugger didn't test 32-bit (and neither, of course, had I), so we
didn't notice until the next day that I'd only added the new check to
the 64-bit codepath. Let's just unify the two, since there's only one
line of meaningful difference.
Bug: http://b/261092827
Test: treehugger
Change-Id: I5178257a76fe24a340b3659c85ad29ed0a7b8b50
These two will stay behind when we move memcpy()/memmove()/memset() over
to arm-optimized-routines (which leaves fortify to us).
Test: treehugger
Change-Id: Ie683f71a5a141263ce3f4e8811df9eaf667584f4
I can't find this documented anywhere, other than people observing that
RISC-V appears to behave in this way. See the LLVM commit making a
similar change to similar code, for example: https://reviews.llvm.org/D87579.
Unsatisfying, but it works, and I suspect we're all too far down this
copy & paste hole to get back out now. See also psabi bug
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/18 for
more discussion.
Change-Id: I9e9d60bf859715895370861b2024deeb1d330577
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
These have been aliases for strtoll() and strtoull() since L, by
accident. We've never exposed them in the headers, and they're unused by
any apps. Let's fix the inconsistency between libc.so and its headers by
removing the aliases.
Bug: https://github.com/android/ndk/issues/1803
Test: treehugger
Change-Id: I87de7831c04b3e450a44e9f0386cacb73793e393
Actually, we don't want to reuse the kernel struct ucontext because its
uc_mcontext has the wrong type, which means the fields within that end
up with the wrong names. Add the call site that made that evident, and
update <sys/ucontext.h> appropriately.
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
Change-Id: If1d079afef0d5953aa22d9b0e049cfb0119c7718
risc-v doesn't have renameat(2), only renameat2(2). Similar to other
architectures, let's make sure everyone's on the same code path by
having all implementations of renameat() go via renameat2().
I've also moved the existing rename()-in-terms-of-renameat() to be in
terms of renameat2() to cut out the middleman!
Test: treehugger
Change-Id: Ibe5e69aca5b39ea014001540bcd4fd3003e665cb
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
Noticed by "NRK": https://www.openwall.com/lists/musl/2022/07/29/5
We don't have this problem elsewhere in bionic because it's so rare to
call getline() without a loop, and the free() is always outside the loop
because that's a handy optimization.
Test: treehugger
Change-Id: Iff8845aa226d87357b38cf4a285fc1be3cac5659
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
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
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
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
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
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 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
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
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
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 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
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
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
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 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
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
