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)
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
(cherry picked from commit 3e4c076ef2)
Convert to use std::atomic directly.
Consistently use relaxed ordering for increments, release ordering
for decrements, and an added acquire fence when the count goes to
zero.
Fix what looks like another race in attemptIncStrong:
It seems entirely possible that the final adjustment for
INITIAL_STRONG_VALUE would see e.g. INITIAL_STRONG_VALUE + 1,
since we could be running in the middle of another initial
increment.
Attempt to somewhat document what this actually does, and
what's expected from the client. Hide the documentation in
the .cpp file for now.
Remove a confusing redundant test in decWeak. OBJECT_LIFETIME_STRONG
and OBJECT_LIFETIME_WEAK are the only options, in spite of some
of the original comments.
It's conceivable that either of these issues has resulted in
actual crashes, though I would guess the probability is small.
It's hard enough to reason about this code without the bugs.
Bug: 28705989
Change-Id: I4107a56c3fc0fdb7ee17fc8a8f0dd7fb128af9d8
(cherry picked from commit e263e6c633)
strcmp needs a limit, otherwise it will compare the null terminator
with the next character in the haystack, which results in the compare
failing for all searches except where the needle is found at the very
end.
Bug: 28663748
Change-Id: I1939dc4037c2f2a75d617943b063d2d38a8c5e3a
These are needed for aapt to find javadoc comments that contain
"@removed" in order to skip them when printing styleable docs.
Bug: 28663748
Change-Id: I8866d2167c41e11d6c2586da369560d5815fd13e
pid_t is 64-bit in 64-bit mingw, but the windows process/thread
functions return a DWORD(uint32_t). Instead of promoting to a pid_t and
fixing the format strings, just use a uint32_t to store the values.
android_thread_id also cannot be a 64-bit pointer, so for windows just
force it to be a uint32_t.
libutils/ProcessCallStack only works under Linux, since it makes heavy
use of /proc. Don't compile it under Windows or Darwin.
Bug: 26957718
(cherry picked from commit 86cf941c48)
Change-Id: I8d39d1951fea1b3011caf585c983e1da7959f7c0
This change is a workaround for apps linking
libutils statically and dynamically which causes
them to crash for newer version of Android.
Bug: http://b/27313399
Change-Id: I47ac4146041b6eeef03cb605ea436719d552ec8f
Arguably we should migrate to std::shared_ptr
but for now make std::vector<sp<>> a bit less
horrible
Change-Id: Ia458a2daff0b656b2f3310b3ea100565ec844c69
FileMaps should be movable, thereby not requiring them to be only used
with a unique_ptr as they currently are.
Change-Id: I0fb8013bf398a2ced5420d85ba888c2a7fc5a496
Some methods in header files of classes using SharedBuffer need
to be moved to the implementation files accordingly
Change-Id: I891f3ace2b940ab219e4e449040bfed71c0547db
