Replaces libbacktrace in CallStack. There is one small behavioral
change, the BuildId data is added to the unwinds.
Bug: 120606663
Test: All unit tests pass.
Test: Run the fuzzer for over an hour without any crashes.
Change-Id: Ic8a4247c515ce0d3cdc4d2cc15167d1948b15fa5
Let's turn a bug into a feature... Since this code is built with intsan,
anyone who caused overflow here will have had an abort, so we know
no-one actually needs the BAD_INDEX return that was presumably the
original author's intent. So let's just mandate that, since it's a lot
harder to ignore an abort than it is to ignore an error return.
Bug: http://b/179044558
Test: treehugger
Change-Id: I08f1018f9da1e09de885699138b7543d55bb2a36
Mark this as 29 for easy inclusion in APEXes when debugging. Make
sure we don't introduce calls to things here which would prevent
this from being used on old platforms.
Fixes: 228561718
Test: build
Change-Id: I2574455dbfe681117e4afcf6eef3546be51393fa
The callback can be called by the destructor of LruCache, so it needs to be destructed last.
Bug: 227635615
Change-Id: I7d965a2000c1ec32d9c9e88d25ab0c1ba3e9c739
For convenience, builds against musl libc currently use the
linux_glibc properties because they are almost always linux-specific
and not glibc-specific. In preparation for removing this hack,
tweak the linux_glibc properties by either moving them to host_linux,
which will apply to linux_glibc, linux_musl and linux_bionic, or
by setting appropriate musl or linux_musl properties. Properties
that must not be repeated while musl uses linux_musl and also still
uses the linux_glibc properties are moved to glibc properties, which
don't apply to musl. Whether these stay as glibc properties or get
moved back to linux_glibc later once the musl hack is removed is TBD.
Bug: 223257095
Test: m checkbuild
Test: m USE_HOST_MUSL=true host-native
Change-Id: I076fa026d7dddfccfa5cc395dd06bdc979eee1d8
TEMP_FAILURE_RETRY uses typeof which is only allowed by gcc and clang
for GNU dialects. This switches to __typeof__ which is always supported.
Bug: 224644083
Test: m
Change-Id: I96d48d2f0dc5cd9ab903755d93c71c4eb80f7529
Some systems (originally only Windows) define their own
NO_ERROR macro that overlaps with the enumerator from Errors.h.
The enumerator is only defined if the macro was not.
Bug: 224644083
Test: m
Change-Id: Iee0932b5259b3bfcf6494656b27e6e7488319f5c
To keep libutils (and consequently libbinder) as compact
and portable as possible, this disables call stacks on all
operating systems except Linux and Android.
Bug: 224644083
Test: m
Change-Id: I0d77c49022e852c2b8607f555174c4f9d54ed3df
This code was a bit confusing because Android runs with an old debug
mode on. The flag around this is removed to make it more clear what
is going on, and the log is promoted D -> W.
Bug: N/A
Test: boot, check logs
Change-Id: I4645b1a7b8e252336a6f9482ce6b57e1b907619d
OkOrFail<status_t> has specialized conversions for Result<int, StatusT>
to avoid ambiguous implicit conversion sequences. Since user conversion
operators sequences can be followed by integral promotion, specializing
for integral types is necessary.
Specialize ResultError<StatusT> so calling code() returns a status_t
instead of a StatusT and message() is implemented even when not carrying
a string.
Eventually, these classes should be combined.
Add equality operators for ResultError<StatusT>.
Bug: 219580167
Test: atest Errors_test.cpp
Merged-In: I14acecfd2aef33c40e79ddb091e2f4af9291d837
Change-Id: Ifb5ed3c2d3452b10901e4aeb19368d873225d9ce
With our recent change 0455a2c39c,
there's some logic that can be simplified to make this slightly
easier to read.
This CL does not change the behavior of this code.
Bug: 208895940
Test: TreeHugger
Change-Id: I4de2dbaf4406cbb7785df8839bb3ae453186ea69
:)
This pulls in quite a few things into a lot of processes. Removing it
separately, in case the use of SetTaskProfiles needs to be reverted,
removing this as well might cause that revert to have linker errors
if new static users of libutils are introduced in the meantime.
Bug: 208895940
Test: build
Change-Id: Iaf5b5d41328c1b1f50bb32be8a6a1bd3a0c3f22f
Threads should always be in the same state as their parents. This also
implies that the additional SetTaskProfiles is unnecessary when
creating a new thread.
Test: boots, TH
Bug: 208895940
Change-Id: Id971c6e87d342a695bea106cdd258bc0ef6f7ecb
musl libc defines NULL as nullptr, which is explicitly allowed by
C++11. nullptr_t cannot be implicitly cast to an integral type.
Use 0 instead.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I0c3b6c94cd69262f574414bf52494333f2f2645a
This change provide a specialization of android::base::OkOrFail for
status_t. As a result, a statement whose type is status_t can be used
with OR_RETURN.
The specialization also provides conversion operators to Result<T,
StatusT> where StatusT is a wrapper type for status_t. This allows
OR_RETURN macro to be used in newer functions that returns Result<T,
StatusT>.
Example usage:
\#include <utils/ErrorsMacros.h>
status_t legacy_inner();
status_t legacy_outer() {
OR_RETURN(legacy_inner());
return OK;
}
Result<T, StatusT> new_outer() {
OR_RETURN(legacy_inner()); // the same macro
return T{...};
}
Bug: 209929099
Test: atest libutils_test
Change-Id: I0def0e84ce3f0c4ff6d508c202bd51902dfc9618
1) App doesn't have cgroup access and there is no purpose of reading cgroup
for app. For system_server it should be known in foreground group. So
there is no benefit of reading group.
2) Reading cgroup in apps can also cause contention for other cgroup
operations.
3) vendor can change cgroup setting and get_sched_policy may return
incorrect information for get_sched_policy_profile_name.
Test: Boot
Bug: 210011562
Signed-off-by: Wei Wang <wvw@google.com>
Merged-In: I8e8c8b346984781c56ec93c0616121f7d5c99fe5
Change-Id: I8e8c8b346984781c56ec93c0616121f7d5c99fe5
(cherry picked from commit defb7773121545130fff80928ebcd7d6015be1d1)
This entry is redundant, as system_shared_libs by default includes
libdl.
This should be a no-op change for the current build system, but avoids
an issue on the alternative (experimantal) build system, Bazel.
Test: md5sum libutils.so before/after on aosp_flame, verified no changes
Change-Id: I18f6e67c3e23299a0f1e0ef530a0a809b068dc03
Previously, Looper internally kept track of the requests to add fds
using the fd value itself. It used an internal sequence number
associated with each request to add a callback to avoid a situation
where a callback is unexpectedly called. However, since it used the fd
value rather than the sequence number to register events into epoll,
there was still a way where unintended hangups could occur.
This exact sequence of events caused unintended behavior in Looper:
- An fd (FD) is added to the looper.
- Looper registers FD into epoll using its FD number.
- FD is closed.
- A hangup event arrives from epoll_wait while the Looper is polling.
Looper is waiting for the lock to process the callback for FD, because
it is blocked by:
- A new fd is created and added to the looper. Since the lowest number
fd is reused, this new fd has the same value as FD.
- The poll request for Looper is now unblocked, so it looks up the
callback associated with FD to process the hangup.
- Since FD is already associated with the new callback, the new callback
is called unintentionally.
This CL uses the sequence number to register fds into epoll. That way,
when we get a hangup from epoll that is associated with a sequence
number, there is no way an unexpected callback will called.
This CL also adds a test to verify this behavior. Due to the
nondeterministic nature of this multi-thread scenario, the test verifies
this scenario repeatedly. Without the fix in Looper, the test is flaky,
but should never fail after the fix.
Bug: 195020232
Bug: 189135695
Test: atest libutils_test --rerun-until-failure
Ignore-AOSP-First: Topic CL aosp/1799831 has a merge conflict with
internal master, resolved in ag/15613419.
Change-Id: Ib4edab7f2407adaef6a1708b29bc52634f25dbb6
A lot of things had moved out of system/core/ without their TEST_MAPPING
entries having gone with them, reducing the amount of presubmit coverage
for those things.
In order to reduce the likelihood of that happening again, I've pushed
all that remained in the system/core/ TEST_MAPPING down into the
individual subdirectories.
Test: treehugger
Change-Id: Ib75d65f9200fa64ae1552471da6fbe5b7023cf94
This reverts commit 70d9fb63e6.
Reason for revert: Outstanding usage of this method removed internally
Change-Id: Idcc00ec261aa1d97f11e47abdb08b10a37b5d20f
Test: Local build; treehugger (which I'll manually confirm runs on the appropriate targets)
String16's ctors already handle static strings, so we don't need a
specialized constructor which accepts StaticString16.
Bug: n/a
Test: libutils_test
Change-Id: I93a1ba70d743ff9c73f113d53ffba73cef6adade
String16 is still in use by AIDL compiler. Because String16 is not
noexcept-move-constructible, the C++ compiler will complain when it is
used with non-copyable types (such as ParcelFileDescriptor).
For example, when vector<Foo> is resized, copy-ctor of Foo is called,
which is not available.
parcelable Foo {
String s;
ParcelFileDescriptor[] pfds;
}
By providing noexcept move-ctor for String16, vector<Foo> can be resized
with no problem.
Btw, copy from StaticString16 is specialized for efficiency and move
from StaticString16 don't need to be different from copy.
Bug: 192136980
Test: libutils_test
Change-Id: I13744a2ceebf5781c3ef7f3a04237a6750b0db0a
