The atrace buffer does not need to be zero-initialized every time.
Test: memset calls from atrace_{begin,end}_body are gone
bug 155788214
Change-Id: I8082b6a9e6d6328f4aee3a22137977e9fae21933
When merging in recovery, the "imminent data wipe" code was used, which
made the assumption the /metadata and /data state would be zapped. This
caused future OTAs to error because the old snapshots were detected.
This CL allows OTAs to proceed even if unexpected snapshots are present.
It also forces the state to "MergeCompleted" after a merge in recovery,
so that the next normal boot can perform cleanup.
Bug: 155339165
Test: fastboot snapshot-update merge, then take another OTA
vts_libsnapshot_test
Change-Id: Ief6dea3ba76323044e61307272dda320a4494aea
Merged-In: Ief6dea3ba76323044e61307272dda320a4494aea
Libunwindstack would remove duplicated items and update the `prev_map`
during reparsing `/proc/self/maps`. But we leave `prev_real_map`
pointing toward a MapInfo that will be deleted soon. It will cause a
dangling pointer issue.
Add new tests to cover this dangling pointer issue.
Bug: 155511785
Test: libunwindstack_test
Change-Id: I62e1b97bcb73f07e9349671f0b758f5ec9de16c0
(cherry picked from commit a7a194beb4)
Introduce new command to allow setting task profiles from inside .rc
script. This is to replace usage of writepid when a service is trying
to join a cgroup. Usage example from a .rc file:
service surfaceflinger /system/bin/surfaceflinger
task_profiles HighPerformance
Bug: 155419956
Test: change .rc file and confirm task profile is applied
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0add9c3b363a7cb1ea89778780896cae1c8a303c
Merged-In: I0add9c3b363a7cb1ea89778780896cae1c8a303c
This won't happen in practice because device size is never
zero. Hypothetically, if it is, PartitionCowCreator still
suggests that a CoW size of 8192 bytes needs to be created. In
reality, it is not necessary.
Test: libsnapshot_fuzzer
Bug: 155484992
Change-Id: I6c69f54820522d50c699384eec90c474ca3a9402
(cherry picked from commit bc84824e21acfdc83590d6d0d4827bd9854fc0f5)
Merged-In: I6c69f54820522d50c699384eec90c474ca3a9402
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 152655956
Test: m
Merged-In: Icd184c6fe06a688bd79ef6514bb49dffb706a9a1
Change-Id: Icd184c6fe06a688bd79ef6514bb49dffb706a9a1
(cherry picked from commit cc3588afcb)
Operations on (unsigned long) f_bsize and f_bfree are correctly handled
on 64 bit architectures, but when switching to 32 bit, the
multiplication between the two could result in an overflow, causing the
test to crash.
Fix by using a uint64_t operand, hinting the compiler to handle the
whole multiplication with 64 bit operands.
Bug: 154355449
Bug: 148889015
Test: vts_libsnapshot_test (32 bit)
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: Ief5c03ff7954c4a3e8597ef6e7df467f59428877
Merged-In: Ief5c03ff7954c4a3e8597ef6e7df467f59428877
1. delete-logical-partition was deleted
- After merge "Don't require bootloader fastboot for VTS compliance." commit, delete-logical-partition sequence was deleted in LogicalPartitionCompliance test. "create-logical-partition failed" is occurred when run vts fastbootverification module. So restore this sequence.
Test: run vts -m VtsFastbootVerification
Bug: 153913610
Signed-off-by: Yongcheol LEE <yongcheol09.lee@lge.com>
Change-Id: I00366b281eafa5677b0941419a86f2702fb3484b
Merged-In: I00366b281eafa5677b0941419a86f2702fb3484b
This test is repeatedly seen to be flaky. Disable it until we can run
tests against a dedicated logd instance.
Bug: 155146087
Test: logd-unit-tests
Merged-In: I0cd953955f613e40d17df73f70543d7d2f0925b6
Change-Id: I0cd953955f613e40d17df73f70543d7d2f0925b6
(cherry picked from commit 25a4d708e2)
Bug: 153849221
Test: build and try to capture the trace by perfetto and systrace
Change-Id: Ie8a13e12038bd66afcd264079a2c5f25daaa20ee
Merged-In: Ie8a13e12038bd66afcd264079a2c5f25daaa20ee
(cherry picked from commit 9d19a05422)
The StringPrintf one is heavily used and brings the overhead versus
fmtlib down to 1.5x rather than 2x. I don't have a convenient benchmark
for the other two.
Test: libbase tests & benchmarks
Bug: http://b/155324241
Change-Id: I9e704a360846d5520c53f668e7c315b0c0ea55f8
(cherry picked from commit 8c253d4d42)
When the subcontext code was redone to allow only one subcontext
(vendor_init), the code for restarting it and for terminating it
during shutdown was not updated, resulting in it not working.
Bug: 155203339
Test: kill subcontext init and notice it restart
Test: subcontext init stops during shutdown
Merged-In: Ib77f59d1e7be0ffcfd3f31c8450dc022c20bb322
Change-Id: Ib77f59d1e7be0ffcfd3f31c8450dc022c20bb322
(cherry picked from commit e3e77d382f)
These historically used atomics to manage their lifetime. They were
unfortunately unsafe and later replace with a RwLock. A lock is
also problematic as it is too heavy weight for the typical use case
and implies that logging is neither async nor fork safe.
This change returns us to using atomics with two key changes:
1) compare_exchange_strong() is used instead of atomic_exchange().
The latter has a race condition where a separate thread could have
read the atomic value into a register, while the thread performing
the atomic_exchange closes that FD. The new code only changes the
FD in the atomic if it is uninitialized.
2) Using the fact that DGRAM sockets can have connect() called on them
multiple times, it uses a single logd_socket for the duration of
the program.
These sockets are thread/async/fork safely created and accessed.
The one caveat is __android_log_close(), which is intended only to be
used by zygote when it is single threaded and is therefore not thread
safe. It will close this socket and reset the underlying variable,
such that the next log message will go through the above
initialization.
Bug: 65062446
Test: logging works, logging unit tests
Test: new unit test
Merged-In: Ia4dbf7479dbe50683d124558ab2f83bff53b8f5f
Change-Id: Ia4dbf7479dbe50683d124558ab2f83bff53b8f5f
(cherry picked from commit 7acfba274c)
The test is guaranteed to fail because userdata is itself a fiemap-backed device.
Bug: 154447105
Test: fiemap_writer_test on DSU
Change-Id: Ied35da0eb7aba3daca7ed430f006bf1e90e21dca
Merged-In: Ied35da0eb7aba3daca7ed430f006bf1e90e21dca
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 152655956
Test: m
Merged-In: If4ff1fbc31e5be3f5611a4713ae4032aba4ee5f2
Change-Id: If4ff1fbc31e5be3f5611a4713ae4032aba4ee5f2
(cherry picked from commit 3851f7e836)
Previously, we would split messages by line and call the logger
function for each line. We would hold a lock during this, to ensure
that multiple threads would not interleave their messages.
There are a few problems with this approach:
1) Using a lock is not efficient and is not fork safe
2) With APEX, there is one lock per instance of libbase, so we must
move the lock to a location where all instances can access it, or
perform the line splitting in a way that does not require the lock.
To solve these issues, we reimagine line splitting.
1) We move the lock out of the LogMessage::~LogMessage() and make it
the logger's responsibility to split lines, giving the logger the
option to lock or not.
2) We do not need any locks at all for StderrLogger.
Instead, we generate a single string that contains all of the lines
with their appropriate log header. A single write() call is used
to output this at once.
3) Logd handles log messages with newlines correctly, however it only
accepts up to a maximum size of log message. Therefore we
separate the incoming log message into chunks, delimited by new
lines, up to that maximum size, and send each of those to logd.
Note that this is the strategy used in
android.util.Log.printlns().
This should solve a majority of use cases, since the maximum size
that logd accepts is nearly 4K, while remaining lock free.
If interleaving messages absolutely must be avoided, a lock can
still be used given 1) above.
Bug: 65062446
Bug: 153824050
Test: logging, particularly multi-line stack traces, show correctly
Test: existing and new unit tests
Change-Id: Id0cb5669bee7f912da1e17f7010f0ee4c93be1e3
(cherry picked from commit 36d31c530d)
These shared_libs are missing from /system/lib/ on 64-bit devices.
Test: Build, install, and run 32bit vts_libsnapshot_test.
Bug: 154115505
Change-Id: Iaf2014748546a055d35e4fe0e24969eef13db7fa
Debugging information for addressing the reason why the process stops as
a zombie, can be found by observing the call trace and running status of
threads in thread group of the zombie process.
Bug: 154667692
Change-Id: Icd7fa2161e88b08fd5ce0d5dc3a3790ed4ac02d1
(cherry picked from commit e5a09d8da5)
Fixes:
system/core/base/include/android-base/result.h:
133:94: warning: potentially unintended semicolon [bugprone-suspicious-semicolon]
Bernie says:
it probably means that there's a parser bug with "if constexpr"
maybe, at static analysis pass, the "if constexpr" was evaluated to false,
and the compiler removed the "then" block from the AST...
... and then it thought you had written it that way :-)
https://reviews.llvm.org/D46027
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I25df8eeca4ec06b3180c1cd21b554fc583c5581a
Merged-In: I25df8eeca4ec06b3180c1cd21b554fc583c5581a
Fixes:
system/core/base/include/android-base/expected.h:
186:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
195:22: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
611:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
To quote Tom Cherry:
I'm a bit confused at what's happening there.
I think it's a bug in the linter itself.
The general solution to that problem is a heavy dose of std::enable_if<>
to hide that constructor when the 'U' parameter is the same class,
but those constructors do have the necessarily std::enable_if<> lines.
I think the problem is that the linter doesn't check that the macro
_ENABLE_IF() expands into std::enable_if<>. Let me try explicitly
putting the std::enable_if<> instead of the macro and check if it
goes away.
I expanded the macro but the linter doesn't still doesn't accept
the format of `std::enable_if_t<(condition_here)>* = nullptr`.
It does accept `typename Enable = std::enable_if_t<(condition_here), void>`,
which is the syntax used on their example here:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-forwarding-reference-overload.html.
That latter syntax doesn't work for us.
See the Notes section on
https://en.cppreference.com/w/cpp/types/enable_if
as a reference for why what we're doing is correct.
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I493ff19208cc104f5f176a36ec23fbcb914388f7
Merged-In: I493ff19208cc104f5f176a36ec23fbcb914388f7
