We have data that indicates that we no longer need to export the libgcc
unwinder's implementation detail symbols from libc.so, as well as the entire
unwinder interface from libm.so, so stop exporting them.
Bug: 144430859
Change-Id: Iebb591c4a121abe6368d9854ec96819abe70a006
malloc debug and malloc hooks have been broken for a long time
and no one noticed. So add them to be run by default on bionic
changes since that provides the most coverage.
Change the malloc debug and malloc hooks tests to support isolated
runs.
Changed the name of the malloc hooks unit tests to system tests
because they weren't really unit tests.
Changed the verify leak malloc debug tests to print out extra
information so it is possible to figure out what sized allocation
failed.
Test: Ran tests.
Change-Id: Idea4c864f1d62598148ee78d7c9397e45234b1ca
For reasons explained in the code comment, go back to roughly our old
code. The "new" tests are just the old tests resurrected.
This also passes the current toybox xargs tests, which were the
motivation for going back on our earlier decision.
Test: bionic and toybox tests
Change-Id: I33cbcc04107efe81fdbc8166dc9ae844e471173e
Currently, scudo doesn't call libc's malloc initialisers. This causes
problems with any functionality that relies on an initialised__libc_globals
inside of bionic malloc's stubs (e.g. malloc()).
This manifests in two ways (that I can think of):
1. Dispatch tables don't work with scudo, so malloc_debug has never
worked in an executable linked against scudo.
2. Allocators that require initialisation and are called from bionic
malloc's stubs (GWP-ASan) never get initialised.
Bug: 135634846
Test: atest bionic-unit-tests-scudo
Change-Id: I3e3344d7d510ce4e8d3709cd69c8cb0fe5adedda
pthread_atfork may call malloc() during its once-init. This causes
problems with allocators (GWP-ASan) that require explicit initialisation
before calls to malloc().
Bug: 135634846
Test: atest bionic
Change-Id: I1810a00465db99d5aa34fa6f74dea5908a628d3a
The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Bug: 143765505
Test: m
Merged-In: I56e49876410bd43723a80d0204a9aef21d20fca9
(cherry picked from commit 3e2cd44aa4)
Change-Id: I56e49876410bd43723a80d0204a9aef21d20fca9
This library was previously being statically linked into both libraries as a
consequence of the relocation to __aeabi_unwind_cpp_prX present in most object
files. However, after LLVM commit 1549b469, we no longer emit these relocations
on Android, so we need to link the library explicitly with --whole-archive. The
intent is to eventually stop linking libgcc into these libraries altogether,
but for now, we need to keep linking them in order to avoid breaking the build.
Change-Id: I275109527b7cbd6c4247b3fe348975d720626273
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
