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
Dan Albert