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
This reverts commit 65bdf655c4.
Reason for revert: checking the failure of avd/avd_boot_test
Bug: 197781964
Change-Id: I70eb03b45cdfbd87ef6edb03b74ad6d1970dc08c
Bug: http://b/157914307
This pragma enables
- -frounding-math, i.e. rounding mode set at runtime are honored
- -ffp-exception-behavior=strict, i.e. FPE semantics are preserved.
- Prevents use of FMA instructions.
Test: Build toolchain without revert https://r.android.com/1298100
and run bionic-unit-tests.math_h*
Change-Id: I6249b20c93e0fd4ebbdfbe433da4ad4a65d3747b
A recent change to lld [1] made it so that the __rela?_iplt_*
symbols are no longer defined for PIEs and shared libraries. Since
the linker is a PIE, this prevents it from being able to look up
its own relocations via these symbols. We don't need these symbols
to find the relocations however, as their location is available via
the dynamic table. Therefore, start using the dynamic table to find
the relocations instead of using the symbols.
[1] f8cb78e99a
Change-Id: I4a12ae9f5ffd06d0399e05ec3ecc4211c7be2880
In order to support demangling of rust symbols by the linker, we are
adding a small Rust component. Rust expects `memalign` to be present in
hosted environments, and it doesn't appear costly to enable it.
Bug: 178565008
Test: m, killall -11 keystore2 produced mangled names in tombstone
Change-Id: I8fc749000fa02a3b760c8cc55be3348b9964d931
Musl doesn't define __NR_clock_gettime and __NR_gettimeofday on
32-bit architectures, #define them to __NR_clock_gettime32 and
__NR_gettimeofday_time32 respectively.
Bug: 190084016
Test: m USE_HOST_MUSL=true bionic-unit-tests-glibc
Change-Id: Iec9ba776a94639a4b6a3ad42f18dfdb0e3580f02
Modify bionic unit tests that are built for glibc so that they also
build against musl. They don't all pass though:
With glibc:
2 SLOW TESTS
4 TIMEOUT TESTS
313 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
With musl:
11 SLOW TESTS
11 TIMEOUT TESTS
363 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
Bug: 190084016
Test: m bionic-unit-tests-glibc with musl
Test: atest bionic-unit-tests-static
Test: atest --host bionic-unit-tests-glibc with glibc
Change-Id: I79b6eab04fed3cc4392450df5eef2579412edfe1
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
Work around the incompatibility between libc++ and !_GNU_SOURCE
by defining a wrapper function around the posix strerror_r in
a file that does not include any libc++ or gtest headers.
Test: bionic-unit-tests-glibc
Change-Id: I6b097079777b5dcd802e295cc566964fe1c01382
The posix spec says strerror_r returns a positive error number, not
-1 and set errno.
Test: bionic-unit-tests-static
Change-Id: I6a12d50d046f9caac299bf3bff63e6c9496c1b6f
Refactor the code a bit to allow retrying if a log message is missing.
This is because there is a possibility of a log message getting dropped.
If that happens, merely rerun up to three times and pass if the missing
message is present.
Also fix a race condition that can occur if the LogReader threads are
being terminated but happen to be allocating memory while they are
in the signal handler. This situation causes aborts in the memory
allocator or a deadlock. Before this change, the verify_leak*
tests would fail in less than twenty iterations. After, I could run
for hundreds of iterations.
Bug: 193898572
Test: Ran unit tests in a loop.
Change-Id: I0fb5beab6041dcf3e3fd19f6748bb20bb81a2506
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: Ie0644412291d3b53dcf89cdd056e542d32822975
These tests can be flaky if something is spamming the log and
expiring messages. Previously, the log wasn't read until the
forked process was complete. Now, two threads are spawned right
after the process forks to read the log while running. This
should avoid any problems if the log is being spammed while the
test runs.
In addition, fixed some potential flakiness in the test that might
occur if the test incorrectly gets stale log data.
Bug: 193898572
Test: All unit tests pass on cuttlefish (both 32 bit and 64 bit).
Test: Forced an abort and verified that the crash log reader sees
Test: the message.
Test: Verified that the log reader for the main and crash log properly
Test: read data.
Test: Verified the test passes while swamping the log by running
Test: the log unit tests while running two copies of the system
Test: tests.
Change-Id: I68bd92a8c483eac0146ada87dd4201dda0902c49
default_shared_libs has been removed, go back to the system_shared_libs
property that now has the same behavior.
Bug: 193559105
Test: m checkbuild
Change-Id: I9edac93f7e6d9d4b99883b7a7b14ab52942c0ef2
Add a utility function to get the current value of a property and
remove some keystore2-specific strings.
Bug: 182498247
Test: Build
Change-Id: Ie7e9903546a4d4cd6c54a118c42257a23510dda6
This is purely a port: it does not add or change any functionality
(other than renaming the library).
Bug: 182498247
Test: Use library.
Change-Id: I4cb8f1c22ca4ca5a398116952fb9957d283d235b
Revert submission 1403568-sysprop_trace
Reason for revert: makes property get/set non-reentrant
Reverted Changes:
I6f85f3f52:Add systrace tag for system property
Id2b93acb2:Adding system property tracing
Id78992d23:Add systrace tag for system property
I1ba9fc7bd:Add systrace tag for system property
Bug: 193050299
Test: build and boot a device
Change-Id: Ic7a83fb01a39113d408ed0c95d27f694d5a2649c
Merged-In: Ic7a83fb01a39113d408ed0c95d27f694d5a2649c
(cherry picked from commit 61a5a8380d)
This reverts commit 1e1c7845aa.
Reason for revert: makes property get/set non-reentrant
Bug: 193050299
Test: build and boot a device
Change-Id: If59e3dc25684a3c2b1d3ff74f995311afe6c6e89
Merged-In: If59e3dc25684a3c2b1d3ff74f995311afe6c6e89
(cherry picked from commit 3ec21f527a)
This is a follow-on to commit 5358cc40ab.
I forgot that there were two places the undefined behavior could occur.
Make the literal unsigned in the other place.
Test: TreeHugger
Bug: 189541929
Change-Id: Iaef81507ca61e802d277246bf5995157c93d86ce
Technically, shifting a signed value beyond its maximum range is
undefined behavior in C++. A bare integer literal is signed, and
defaults to 'int'. On platforms where 'int' is 32-bits, we
shift outside this range with 1 << 31.
We make our literal an unsigned integer to avoid this.
Test: TreeHugger
Bug: 189541929
Change-Id: Iade1bcd3f86d025dd6e10c26622d10c26e2c8295
