* 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
From libc manual for vsnprintf:
The functions vprintf(), vfprintf(), vsprintf(), vsnprintf()
are equivalent to the functions printf(), fprintf(), sprintf(), snprintf(),
respectively, except that they are called with a va_list instead of a
variable number of arguments. These functions do not call the va_end macro.
Because they invoke the va_arg macro, the value of ap is undefined after the call.
We need to allocate/end new va_list for each vsnprintf.
Change-Id: I66ec058033be1cb918e7b2bc84ca546800da226b
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Fix a small bug in the Printer for strings that didn't properly
prepend the prefix.
(cherry picked from commit 9b0e074c6d)
Change-Id: I78bfa3f76864c34f33fb439bf20dfc85616f1077
On devices with an up-to-date kernel, the back-in-time bug affecting
clock_gettime() has been fixed and it can safely be used as an
alternative to the ANDROID_ALARM_GET_TIME ioctl. To ensure consistent
behavior on existing devices, make clock_gettime() a fallback for when
the alarm driver isn't available.
Change-Id: I384af5e7ec9e73e0bad4b6b0f987a8ea4583cba6
Signed-off-by: Greg Hackmann <ghackmann@google.com>
1. When alloc or realloc failed in the function SharedBuffer::editResize,
it would return a NULL pointer, then mStorage would update to be 1 by
SharedBuffer::data() if no pointer check here, which is an obviously
wrong address, and would cause corruption when used it e.g. in capacity().
So add the pointer check here for the return value of SharedBuffer::editResize,
if it's NULL do not use it to update mStorage, to avoid the value of mStorage
polluted.
2. when alloc or realloc falied in _grow & _shrink function, mStorage keep
the original value, so mCount should not be updated here.
Otherwise, mStorage might be 0 but mCount>0, so a corruption would happend
when it try to delete items from the Vector since mCount>0.
Change-Id: I7c3814e843c459834ca5eed392e8d63d1cb7d2d8
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Jian Luo <jian.luo@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 139626
The kernel problem has been fixed long time ago and the ad-hoc logging
mechanism is not thread safe and can flood the log with spurious
messages.
BUG: 10899829
Change-Id: I63278db51295e744eed3e47dc8d4cfe621c0d8f7
