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
