Test accessing a singleton from two libraries, the second of which
depends on the first but is dlopen'd after the first is already
loaded.
Bug: 35674422
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
Change-Id: I975ba933a19b941a52bdb6e9c221a6910ffb8081
Reapply of Icd5f39ae71b57167e9b2fe7ec09c5400bcb90e78 with
RefBase_test.cpp and Looper_test.cpp removed from mac builds.
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
Test: out/host/darwin-x86/nativetest64/libutils_tests/libutils_tests
Change-Id: I5979b296a8500b5697d94d64fc441363047adcea
StrongPointer_test.cpp's Foo was colliding with RefBase_test.cpp's
Foo.
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
from later CL
Change-Id: I2a4e956c88a07cec72d7ce734cf06c58134a4235
I385a05a3ca01258e44fe3b37ef77e4aaff547b26 broke Singleton in the
same way that 544e3e3606 had already
fixed once. Fix it again, the next CL will add tests.
This affected cases where two libraries referenced the same singleton,
the one that was supposed to define the singleton was already loaded,
and then the second library was dlopen'd.
Bug: 35674422
Test: out/host/linux-x86/nativetest64/libutils_tests/libutils_tests
from later CL
Change-Id: I87c64f95ed294a887e67a6c11be3072299789f01
Changes to the REALTIME clock can cause Condition::waitRelative() to
timeout early or delayed. This behavior is undesired and new since
https://android-review.googlesource.com/#/c/181058/ moved the
underlying pthread_cond_timedwait() implementation to use absolute
timeouts rather than relative ones. Having Condition use
CLOCK_MONOTONIC prevents these timeout issues.
Bug: 34592766
Bug: 35678943
Test: Boot bullhead
Test: Ensure time changes do not cause Condition::waitRelative() to
timeout early or delayed
Change-Id: I3a8d7a48f9b42fe990c3c7331313b6d85aa546f9
If we don't output to stderr too, not only is it annoying to shell users (who
won't see anything), it prevents us from writing better gtests that actually
make assertions about the assert message.
Bug: http://b/23675822
Test: libutils tests still pass
Change-Id: I62b3144c385cba4dde485f0b0f9b42aeaef51e9a
Moved headers from include/libutils and include/libsysutils to
libutils/include and libsysutils/include respectively, so they can be
exported via these libs. They needed to be moved since Soong does
not allow export from external folder.
Added symlink from old locations. They are needed since Soong
includes system/core/include by default. Once all modules are
cleaned up to explicitly add the required libs, the symlinks will be
removed.
Moved headers of libutils to libutils_headers. They should be used
by modules for header-only inlines. Added libutils_headers as
dependency of libutils.
Split of C++ headers into those that have no dependency and those that
have dependency on libutils.so will be handled in a later CL.
Test: Add above libs to shared lib of local module
Change-Id: I122db72056b26b1f39bad1d9a0c2a1c5efda3550
Point to log/log.h where necessary, define LOG_TAG where necessary.
Accept that private/android_logger.h is suitable replacement for
log/logger.h and android/log.h.
Correct liblog/README
Effectively a cleanup and controlled select revert of
'system/core: drop or replace log/logger.h' and
'system/core: Replace log/log.h with android/log.h'.
Test: compile
Bug: 30465923
Change-Id: Ic2ad157bad6f5efe2c6af293a73bb753300b17a2
Should use android/log.h instead of log/log.h as a good example
to all others. Adjust header order to comply with Android Coding
standards.
Test: Compile
Bug: 26552300
Bug: 31289077
Change-Id: I33a8fb4e754d2dc4754d335660c450e0a67190fc
Should use android/log.h instead of cutils/log.h as a good example
to all others. Adjust header order to comply with Android Coding
standards.
Test: Compile
Bug: 26552300
Bug: 31289077
Change-Id: I2c9cbbbd64d8dccf2d44356361d9742e4a9b9031
The warnings in these files were hidden by -isystem
framework/native/include.
Bug: 31752268
Test: m -j
Change-Id: I2a54376aea380ee24e6483fb7d35fdfe8991c490
system/core/include is included in the global include path using
-isystem, which hides all warnings. Fix warnings in libutils
headers in preparation for moving from -isystem to -I.
- Fix implicit cast from int64_t to long in Condition.h. Remove
the __LP64__ check and always compare against LONG_MAX before
casting.
- Fix implicit cast from size_t to ssize_t in KeyedVector.h
- Fix -Wshadow-field-in-constructor warnings in Looper.h and RefBase.h
- Move destructors for MessageHandler and LooperCallback to Looper.cpp
and ReferenceRenamer and VirtualLightRefBase to RefBase.cpp to prevent
vtables in every compilation unit.
- Declare template variables in Singleton.h
- Fix old-style casts in StrongPointer.h and TypeHelpers.h
- Use template metaprogramming in TypeHelpers.h to avoid warnings on
memmove on non-trivial types.
- Add an assignment operator to key_value_pair_t to complete
rule-of-three
- Use memcpy instead of dereferencing a reinterpret_casted pointer to
treat the bits of a float or double as int32_t or int64_t
- Escape unicode sequences inside doxygen comments between \code and
\endcode
- Remove WIN32 ZD definition in Compat.h, %zd works fine with mingw
- Fix WIN32 printf warnings in Filemap.cpp
- Initialize mNullValue with 0 in LruCache.h, some of the tests use a
non-pointer type for TValue.
Test: m -j native
Bug: 31492149
Change-Id: I385a05a3ca01258e44fe3b37ef77e4aaff547b26
Inconsistent behaviour between utf16_to_utf8 and utf16_to_utf8_length
is causing a heap overflow.
Correcting the length computation and adding bound checks to the
conversion functions.
Test: ran libutils_tests
Bug: 29250543
Change-Id: I6115e3357141ed245c63c6eb25fc0fd0a9a7a2bb
(cherry picked from commit c4966a363e)
String16(const char *utf8) now returns the empty string in case
a string ends halfway throw a utf8 character.
Bug: 29267949
Clean cherry-pick from 1dcc0c8239
Change-Id: I5223caa7d42f4582a982609a898a02043265c6d3
This prevents two different kinds of client errors from causing
undetected memory corruption, and helps with the detection of others:
1. We no longer deallocate objects when the weak count goes to zero
and there have been no strong references. This otherwise causes
us to return a garbage object from a constructor if the constructor
allocates and deallocates a weak pointer to this. And we do know
that clients allocate such weak pointers in constructors and their
lifetime is hard to trace.
2. We abort if a RefBase object is explicitly destroyed while
the weak count is nonzero. Otherwise a subsequent decrement
would cause a write to potentially reallocated memory.
3. We check counter values returned by atomic decrements for
plausibility, and fail immediately if they are not plausible.
We unconditionally log any cases in which 1 changes behavior
from before. We abort in cases in which 2 changes behavior, since
those reflect clear bugs.
In case 1, a log message now indicates a possible leak. We have
not seen such a message in practice.
The third point introduces a small amount of overhead into the
reference count decrement path. But this should be negligible
compared to the actual decrement cost.
Add a test for promote/attemptIncStrong that tries to check for
both (1) above and concurrent operation of attemptIncStrong.
Add some additional warnings and explanations to the RefBase
documentation.
Bug: 30503444
Bug: 30292291
Bug: 30292538
Change-Id: Ida92b9a2e247f543a948a75d221fbc0038dea66c
Add basic interface documentation to RefBase.h.
Much, but not all, of this is cut-and-pasted from an email message
from Mathias Agopian. The rest is reconstructed from the code.
Delete some, now redundant, text from Refbase.cpp, and add a bit
more about the implementation strategy.
Some minor fixes to internal comments.
Bug: 30292291
Change-Id: I56518ae5553bc6de0cc2331778e7fcf2e6c4fd87
Since the equality operator '==' has higher precedence than the
assignment operator '=', we were assigning 'prev' to the result of
our comparison and not the result of mRefs.fetch_sub().
This means that 'prev' would only receive the values 0 or 1. In
the cases where fetch_sub() returned 0 or 1, we were happening to
get the correct value. But if fetch_sub() was greator than 1,
we would return to the user 0, instead of the previous reference
count.
We fix this by properly adding parentheses. We also adjust the
whitespace a little to hopefully make the groupings of the logic
easier to see.
Change-Id: Ib129798a7076854b9ca4f6385c42edbf4fb75e57
The compensating onLastStrongRef call could be made even when there
was no onIncStrongAttempted call to compensate for. This
happened in the OBJECT_LIFETIME_STRONG case when e.g. curCount
was initially zero, but was concurrently incremented by another
thread.
I believe the old code was also incorrect in the
curCount = INITIAL_STRONG_VALUE + 1 case,
which seems to be possible under unlikely conditions.
In that case, I believe the compensating call IS needed.
Thus the condition was also changed.
Bug: 30503444
Change-Id: I44bcbcbb1264e4b52b6d3750dc39b041c4140381
Add some basic tests for RefBase, as well as a more ambitious memory
ordering test.
Add a README.txt with instructions to run the tests.
Comment out a couple of BlobCache tests that failed consistently and
appeared to be incorrect. With that fix, I managed to run
libutils_tests successfully on device.
Bug: 28705989
Change-Id: I8ad29995097a149a0cc38615d6ed37117ec6cb5c
This matches what the Android.mk defined, and should temporarily fix
builds that were broken with:
system/core/libutils/Unicode.cpp:225:12: runtime error: unsigned integer
overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned
long')
Change-Id: I0363b42fc2d62dfd2d05649c9aa9ef0be573e20a
Add comment that SharedBuffer is deprecated.
Both aref and SharedBuffer had memory ordering bugs. Aref has no
clients.
SharedBuffer had several bugs, which are fixed here:
mRefs was declared neither volatile, not atomic, allowing the
compiler to, for example, reuse a stale previously loaded value.
It used the default android_atomic release memory ordering, which
is insufficient for reference count decrements.
It used an ordinary memory read in onlyOwner() to check whether
an object is safe to deallocate, without any attempt to ensure
memory ordering.
Comments claimed that SharedBuffer was exactly 16 bytes, but
this was neither checked, nor correct on 64-bit platforms.
This turns mRef into a std::atomic and removes the android_atomic
dependency.
Bug: 28826227
Change-Id: I39fa0b4f70ac0471b14ad274806fc4e0c0802e78
