Right now, when we read a system property, we first (assuming we've
already looked up the property's prop_info) read the property's serial
number; if we find that the low bit (the dirty bit) in the serial
number is set, we futex-wait for that serial number to become
non-dirty. By doing so, we spare readers from seeing partially-updated
property values if they race with the property service's non-atomic
memcpy to the property value slot. (The futex-wait here isn't
essential to the algorithm: spinning while dirty would suffice,
although it'd be somewhat less efficient.)
The problem with this approach is that readers can wait on the
property service process, potentially causing delays due to scheduling
variance. Property reads are not guaranteed to complete in finite time
right now.
This change makes property reads wait-free and ensures that they
complete in finite time in all cases. In the new approach, we prevent
value tearing by backing up each property we're about to modify and
directing readers to the backup copy if they try to read a property
with the dirty bit set.
(The wait freedom is limited to the case of readers racing against
*one* property update. A writer can still delay readers by rapidly
updating a property --- but after this change, readers can't hang due
to PID 1 scheduling delays.)
I considered adding explicit atomic access to short property values,
but between binary compatibility with the existing property database
and the need to carefully handle transitions of property values
between "short" (compatible with atomics) and "long" (incompatible
with atomics) length domains, I figured the complexity wasn't worth it
and that making property reads wait-free would be adequate.
Test: boots
Bug: 143561649
Change-Id: Ifd3108aedba5a4b157b66af6ca0a4ed084bd5982
aosp/144287300 set it to a global cppflag.
The compiler upgrade can now check for this warning in C code.
This patch should be reverted once the BSD sources with instances of
-Wimplicit-fallthrough have been fixed.
Remove it from cflags, so that it's not re-enabled for C code until
fixed.
Bug: 139945549
Bug: 144287300
Test: mm
Change-Id: Ieca0d5b41634636477392e5209a41807f9b44bd4
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
libc++ poisons `__out` because it's #defined on Windows. Rather than
hack libc++, let's just avoid that name. "src" and "dst" are far more
widely used than "in" and "out" for this purpose anyway.
Test: treehugger
Change-Id: I0db9997fd5f06f626dbf0ee967b52145395466b4
I have no idea why I used the iterate name internally which is
completely unlike every other function name. Change this to match
everyone else so that it's now malloc_iterate everywhere.
This is probably the last chance to change this before mainline
modules begin, so make everything consistent.
Test: Compiles, unit tests passes.
Change-Id: I56d293377fa0fe1a3dc3dd85d6432f877cc2003c
This reverts commit d7e11b8853.
Reason for revert: Droidcop-triggered revert due to breakage android-build.googleplex.com/builds/submitted/5992686/aosp_x86_64-eng/latest/view/logs/build_error.log, bug b/144081298
Change-Id: Ic6a492c4fcf2ea1bb324c44fb615a898bbc9a9b7
This reverts commit d7e11b8853.
Reason for revert: Breaks aosp_x86_64-eng. Will look into it and
unbreak when it's not almost midnight. :)
Change-Id: I21f76efe4d19c70d0b14630e441376d359a45b49
When using a FILE object for some malloc debug functions, calling
fprintf will trigger an allocation to be put in the object. The problem
is that these allocations were not allocated by the malloc debug
wrapper and they get freed during the fclose as if they are malloc
debug allocation. In most cases, the code will detect the bad pointer
and leak the memory, but it might also cause a crash.
The fix is to avoid using fprintf so that no allocations are made
in the object that survive and need to be freed in the fclose call.
Change the MallocXmlElem.h to use a file decsriptor not a FILE object.
Add new unit and system tests to detect this case.
Bug: 143742907
Test: Ran unit and system tests.
Test: Ran bionic unit tests.
Change-Id: I524392de822a29483aa5be8f14c680e70033eba2
