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
If wake() fails to write to mWakeEventFd, the looper is
screwed. This is really a fatal, unrecoverable error,
so treat it as such.
This is possibly an explaination for the unexplained
random ANRs
Change-Id: I5af3e013493b475d8e902d8ee6340f331e5d86c8
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
We refactor this mildly in the hopes of making this a little easier
to follow for future readers. We also go through the dealloc()
method so if we decide to invoke the SharedBuffer destructor in
the future, we only need to remember it in one place.
In addition, this is slightly more efficient in the multi-owner
case, since we no longer subtract to 0 and then (redundantly) set the
reference count explicitly to 0 as well.
Change-Id: Ifc773bd7900c89c36ac24904b2716f02cb57c095
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
String16(const char *utf8) now returns the empty string in case
a string ends halfway throw a utf8 character.
Bug: 29267949
Change-Id: I5223caa7d42f4582a982609a898a02043265c6d3
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
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 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
(cherry picked from commit 3e4c076ef2)
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
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)
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
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
am: 6d28bd81f5
* commit '6d28bd81f55236d1a82f00f8ac568ad61a03128d':
SystemClock: elapsedRealtimeNano() should use clock_gettime() on Linux
Change-Id: Id5ecad63fb6cd79cc7db641d992e9525bc2b8779
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
We've removed the Android alarm driver from our supported kernels.
clock_gettime(CLOCK_BOOTTIME) has been a viable option since 2.6.39, so
there's no need for the legacy code path anymore.
We can use this on Linux hosts too, since no one should be building
Android on hosts with kernels that old.
Bug: 28357356
Change-Id: I0aa164383c95e77c53d2c85883d83f85d4abc7b1
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Also cleans up two instances of open() with useless mode params, and
changes a few uses of snprintf to use sizeof(buffer) instead of
hardcoded buffer sizes.
Change-Id: If11591003d910c995e72ad8f75afd072c255a3c5
* Store the output of a length variable in size_t.
* Annotate unsigned constant values as such.
Bug: 27384813
Change-Id: I8504c0a8f5840d4d42e5c0df797a4e5d02d13eb9
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
(cherry picked from commit 2c7960c8d9)
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
Add utility methods that convert String16 and String8 into
std::string.
Also, remove a repeated include of <utils/Unicode.h> in
String16.h, since it is not used in that header file,
and is already included in String16.cpp.
BUG: 27200800
Change-Id: I5238aeb70689499763060a99dff9950fbb7adb3e
TEST: libutils builds successfully.
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
Change-Id: I4e43e7cf18a96f22b3a9a08dbab8c3e960c12930
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
Use external/safe-iop to check for overflows on arithmetic
operations.
Also remove an unnecessary copy of Vector/SharedBuffer from
codeflinger and use the copy from libutils instead.
Note that some of the unit tests are somewhat useless due to
test-runner limitations : gtest's ability to filter on abort message
doesn't work when combined with messages formatted by android's logging
system.
bug: 22953624
(cherry picked from commit c609c31fb5)
Change-Id: I61644633db6b54fa230683615de9724f7fabf6fb
CYGWIN is not supported, USE_MINGW and HOST_OS==windows are being
replaced with LOCAL_..._windows variables.
Bug: 23566667
Change-Id: I3e4a1e4097dc994cf5abdce6939e83a91758fd75
Use external/safe-iop to check for overflows on arithmetic
operations.
Also remove an unnecessary copy of Vector/SharedBuffer from
codeflinger and use the copy from libutils instead.
Note that some of the unit tests are somewhat useless due to
test-runner limitations : gtest's ability to filter on abort message
doesn't work when combined with messages formatted by android's logging
system.
bug: 22953624
Change-Id: I46b1ae8ca1f3a010be13aca36a091e76a97a7b70
j is a ssize_t, which can go negative. If it goes negative,
the resulting multiplication of mItemSize*j doesn't make
any sense. Since the value is never used, just don't perform
the calculation if j < 0.
Bug: 23607865
Change-Id: I14f6f6506645d582f7d67a2e2d60ead3cb18b957
* Hashing functions rely on integer overflow behavior.
Mark those functions as safe.
* abort() if a passed in size_t value is greater than
UINT32_MAX. This can occur on 64 bit builds where size_t
is larger than uint32_t.
* Special case the index lookup for an empty sorted vector.
Without the special case, size() == 0, and size()-1 underflows.
Change-Id: I343a14b589fc8f0d221c1998ae5d6f0b9e2781f8
It's easier for people to debug, and side-steps the problem that errno
values differ between architectures.
Bug: http://b/17458391
Change-Id: I1db9b2cbb653839d3936b91e37e5cff02671318a
Sometimes it seems like we can get into a situation where we are
unable to remove an fd from the epoll set but it keeps sending us
events anyhow. Defensively rebuild the epoll set in this case
to prevent us from spinning forever.
Bug: 21271428
Change-Id: I5607e565f2e12460d7113a1f62a70d38d334e271
Add a build id field to the header structure in blob cache. Add build
id support with reading and writing the cache. When the cache gets
written it writes the build id at the end of the header. When read it
checks to see if there is a match between the current version and the
version in the cache. If not, it invalidates the cache which would
typically only occur during an ota update. Also remove blob cache
from the host build.
bug: 18262905
Change-Id: I753b1de1986703a4c1c8691b9d2bb533b2546143
When a file descriptor is closed before removing it from the
epoll set, it will normally be removed automatically from the
epoll set by the kernel. However if there exists a duplicate
then the original file descriptor may remain in the set and
continue to receive events until all duplicates have been closed.
Unfortunately due to kernel limitations we need to rebuild the epoll
set from scratch because it may contain an old file handle that we are
now unable to remove since its file descriptor is no longer valid.
No such problem would have occurred if we were using the poll system
call instead, but that approach carries others disadvantages.
Bug: 19715279
Change-Id: If1ab8ebda0825755a416d513e888942a02ee3948
Added code to protect against situations that may occur when a
Looper callback has the side-effect of closing the file descriptor that
it is watching before it returns. This code pattern is very
convenient for implementation but it does expose issues in how
the list of callbacks is maintained. In particular, we
need to watch out for file descriptors which have been reused.
This change may resolve previously unexplained ANRs associated with
log messages such as: "Error modifying epoll events for fd 44, errno=2"
Bug: 10349083
Change-Id: I20eedf6ffbdeda382653ca0104962505194741b0
The loop isn't technically idle at this time, it's just checking
whether any file descriptors have pending events. However it's
still a good signal as to whether the loop is alive.
Bug: 19532373
Change-Id: I555c473e70ffd8a56e1b10aa60026eb674a16de9
Nobody ever called acquire() so release() was always
equivalent to delete. Just use delete instead so that
people can use unique_ptr directly (or shared_ptr if
they really want refcounts).
Change-Id: I9e3ad5e0f6a4fcc4e02e5a2ff7ef9514fe234415
The reference to NOT_USING_KLIBC appears to be the only one
in our codebase. This change also removes some cygwin specific
retry logic - all other supported platforms in this section
of the code should support mapping at an offset.
Note that i've reversed the sense of the check, we always sysconf
since that's recommended practice.
Change-Id: Ib985fb665193d7a07a282f7092cd77c0bc508a66
The actual bug is == instead of !=, but the real cause was me trying to be
too clever. This patch switches to much simpler code, and -- since the
intended use of this code is security anyway -- adds logging if anything
goes wrong.
Bug: 19361774
Change-Id: If2af07d31a5002f9010b838247b691f6b28bdfb1
This isn't particularly useful in and of itself, but it does introduce the
first (trivial) unit test, improves the documentation (including details
about how to debug init crashes), and made me aware of how unpleasant the
existing parser is.
I also fixed a bug in passing --- unless you thought the "peboot" and "pm"
commands were features...
Bug: 19217569
Change-Id: I6ab76129a543ce3ed3dab52ef2c638009874c3de
Only two days in, and I'm already really regretting putting this code
somewhere that builds for Mac OS and Windows...
Change-Id: I576ee4a9e647e10dc2d47c7e1e38aedee2bf404c
I knew I should have created a new library that doesn't build for the
Mac or Windows rather than adding to libutils...
Change-Id: I7c07eaa93affb7e83d4da384f03652c39065562a
Removed LOCAL_C_INCLUDES as the external/zlib headers are no longer
referenced by anything in libutils.
Removed unused host_commonLdlibs build variable. This was referenced
by the lib64utils host target which was removed in commit 03cc1f747
Tested compiling some of the projects that make use of libcutils
using a clean out dir with the folllowing targets
aosp_arm-eng : make -j16 logd dexdump
aosp-flouder-userdebug : make -j16 keystore vold libjavacore logd
aosp-x86_64-eng : make -j16 keystore vold libjavacore logd dexdump
Change-Id: I663e52bbf28dde27866dad9429bf95ada6b594a5
The implementation of the FileMap destructor would
close the file, only on Windows, which did not match
the behavior on mac/linux.
This is because calling munmap does not close the file
descriptor. It must be closed separately, before or after
munmap.
On Windows, the file must also be closed manually,
before or after closing the mappingFile.
The change basically removes the closing file from
the windows-specific part of the destructor, to
make behavior more consistent on all platforms
where the caller to FileMap is responsible for closing
its own file (since FileMap receives an opened file).
Change-Id: I5e3cfffbb870d5f3595802ccac57dbc1dbf1ce6e
The computed flattened size of the blob does not match the size used by the
flatten function when the last cached entry size is not 4 byte aligned.
Bug: 17873145
Change-Id: I9f9fc102d4bde4681ae977b6de5f263aaaf56708
There's an inherent race in trying to read out the thread name from
the system and the thread closing out on its own (and thus being removed
from procfs).
Try to handle this by formatting the thread name unconditionally with
the tid when getting the thread name fails (instead of dereferencing
NULL and crashing).
Bug: 15406837
Change-Id: Ibf2208b8ce345589e7e9c57e6a307728d1121c5d
When flattening the BlobCache, we insert padding for alignment. Make
sure to zero the padding bytes to have reproducible results.
Bug: 16569863
Change-Id: Id39eac5e6a1687459eb6bc2074b1339393fce711
Bug: 16408818
These targets are no longer in use, since we have a proper way to create both
32-bit and 64-bit host libraries in a single build now.
Cherry-pick from AOSP: 03cc1f747c
Change-Id: Icd09f795acd220de5b5e956a8d8e1b4ab4864fa9
Bug: 16408818
These targets are no longer in use, since we have a proper way to create both
32-bit and 64-bit host libraries in a single build now.
Change-Id: Icd09f795acd220de5b5e956a8d8e1b4ab4864fa9
Bug: 15274351
Bug: 15539240
Many MP3 files have incorrect utf16 chars, but the
Utf16_to_utf8_length() routine checks for errors in
standard utf16 char. utf16_to_utf8() was not checking
for errors in standard utf16 char.
Change-Id: Iafd922ff92cabe6bba8971215fcfd1fd471c894b
(cherry picked from commit 605b139cdf56364c6c9b37e59dd12efc61c24631)
- Deal with some -Wunused issues
- Override PRI macros (windows)
- Revert use of PRI macros on off64_t (linux)
- Deal with a gnu++11 complaince issue
Change-Id: Ie66751293bd84477a5a6dfd8a57e700a16e36964
HAVE_POSIX_CLOCKS imples clock_gettime,settime and
CLOCK_REALTIME / CLOCK_MONOTONIC.
CLOCK_BOOTTIME appears only on newer versions of glibc
and might only be supported on newer kernels.
Change-Id: I66e724a3593538c3b80de2c5f81a964d3fa96eaf
This was broken about 5 months ago in change I78435ed49aa196a0efb45bf9b2d58b62c41737d3.
See: https://goto.google.com/jhtss
Change-Id: Icc32993552efed3015bc1b79a7bd872d7510e020
Colin Cross