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)
