This patch is a rewrite of libc.debug.malloc = 10 (chk_malloc). It provides
the same features as the original (poison freed memory, detect heap overruns
and underruns), except that it provides more debugging information whenever it
detects a problem.
In addition to the original features, the new chk_malloc() implementation
detects multiple frees within a given range of the last N allocations, N being
configurable via the system property libc.debug.malloc.backlog.
Finally, this patch keeps track of all outstanding memory allocations. On
program exit, we walk that list and report each outstanding allocation.
(There is support (not enabled) for a scanner thread periodically walks over
the list of outstanding allocations as well as the backlog of recently-freed
allocations, checking for heap-usage errors.)
Feature overview:
1) memory leaks
2) multiple frees
3) use after free
4) overrun
Implementation:
-- for each allocation, there is a:
1) stack trace at the time the allocation is made
2) if the memory is freed, there is also a stack trace at the point
3) a front and rear guard (fence)
4) the stack traces are kept together with the allocation
-- the following lists and maintained
1) all outstanding memory allocations
3) a backlog of allocations what are freed; when you call free(), instead of
actually freed, the allocation is moved to this backlog;
4) when the backlog of allocations gets full, the oldest entry gets evicted
from it; at that point, the allocation is checked for overruns or
use-after-free errors, and then actually freed.
5) when the program exits, the list of outstanding allocations and the
backlog are inspected for errors, then freed;
To use this, set the following system properties before running the process or
processes you want to inspect:
libc.malloc.debug.backlog # defaults to 100
libc.malloc.debug 10
When a problem is detected, you will see the following on logcat for a multiple
free:
E/libc ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 BYTES MULTIPLY FREED!
E/libc ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 ALLOCATED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c658 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d80 /system/lib/libc.so
E/libc ( 7233): #03 pc 4009647c /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
E/libc ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 FIRST FREED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c7d2 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d94 /system/lib/libc.so
E/libc ( 7233): #03 pc 40096490 /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
E/libc ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 NOW BEING FREED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c6ac /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d94 /system/lib/libc.so
E/libc ( 7233): #03 pc 400964a0 /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
The following for a heap overrun and underrun:
E/libc ( 7233): +++ REAR GUARD MISMATCH [10, 11)
E/libc ( 7233): +++ ALLOCATION 0x404b9198 SIZE 10 HAS A CORRUPTED REAR GUARD
E/libc ( 7233): +++ ALLOCATION 0x404b9198 SIZE 10 ALLOCATED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c658 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d80 /system/lib/libc.so
E/libc ( 7233): #03 pc 40096438 /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
E/libc ( 7233): +++ ALLOCATION 0x404b9198 SIZE 10 FREED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c7d2 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d94 /system/lib/libc.so
E/libc ( 7233): #03 pc 40096462 /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
E/libc ( 7233): +++ ALLOCATION 0x404b9358 SIZE 10 HAS A CORRUPTED FRONT GUARD
E/libc ( 7233): +++ ALLOCATION 0x404b9358 SIZE 10 ALLOCATED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c658 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d80 /system/lib/libc.so
E/libc ( 7233): #03 pc 400964ba /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
E/libc ( 7233): +++ ALLOCATION 0x404b9358 SIZE 10 FREED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c7d2 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d94 /system/lib/libc.so
E/libc ( 7233): #03 pc 400964e4 /system/bin/malloctest
E/libc ( 7233): #04 pc 00016f24 /system/lib/libc.so
The following for a memory leak:
E/libc ( 7233): +++ THERE ARE 1 LEAKED ALLOCATIONS
E/libc ( 7233): +++ DELETING 4096 BYTES OF LEAKED MEMORY AT 0x404b95e8 (1 REMAINING)
E/libc ( 7233): +++ ALLOCATION 0x404b95e8 SIZE 4096 ALLOCATED HERE:
E/libc ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
E/libc ( 7233): #00 pc 0000c35a /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #01 pc 0000c658 /system/lib/libc_malloc_debug_leak.so
E/libc ( 7233): #02 pc 00016d80 /system/lib/libc.so
E/libc ( 7233): #03 pc 0001bc94 /system/lib/libc.so
E/libc ( 7233): #04 pc 0001edf6 /system/lib/libc.so
E/libc ( 7233): #05 pc 0001b80a /system/lib/libc.so
E/libc ( 7233): #06 pc 0001c086 /system/lib/libc.so
E/libc ( 7233): #07 pc 40096402 /system/bin/malloctest
E/libc ( 7233): #08 pc 00016f24 /system/lib/libc.so
Change-Id: Ic440e9d05a01e2ea86b25e8998714e88bc2d16e0
Signed-off-by: Iliyan Malchev <malchev@google.com>
Some SoCs that support NEON nevertheless perform better with a non-NEON than a
NEON memcpy(). This patch adds build variable ARCH_ARM_USE_NON_NEON_MEMCPY,
which can be set in BoardConfig.mk. When ARCH_ARM_USE_NON_NEON_MEMCPY is
defined, we compile in the non-NEON optimized memcpy() even if the SoC supports
NEON.
Change-Id: Ia0e5bee6bad5880ffc5ff8f34a1382d567546cf9
Currently the dlmalloc allocates the memory with 8-byte alignment.
According to the com.aurorasoftworks.quadrant.ui.professional benchmark data:
We can get much better memory performance if we change it to be 16-byte aligned.
For example, On Nexus-S:
8-byte aligned :
1378 1070 1142 1665 1765 1163 1179 1263 1404 avg: 1336.555555556
16-byte aligned:
1691 1731 1780 1691 1671 1678 1802 1758 1780 avg: 1731.333333333
gain: 29.53%
That patch provides flexibity to customize the MALLOC_ALIGNMENT from the
board config.The macro MALLOC_ALIGNMENT defaults to 8.
To change it, please define BOARD_MALLOC_ALIGNMENT in the BoardConfig.mk:
BOARD_MALLOC_ALIGNMENT := <whatever>
Change-Id: I8da0376944a0bbcef1d0fc026bfb6d9125db9739
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Beare, Bruce J <bruce.j.beare@intel.com>
So that we can always get the full stack trace regardless of gcc's handling
of the "noreturn" attribute associated with abort().
(Cherry pick of Id264a5167e7cabbf11515fbc48f5469c527e34d4.)
Bug: 6455193
Conflicts:
libc/Android.mk
Change-Id: I568fc5303fd1d747075ca933355f914122f94dac
So that we can always get the full stack trace regardless of gcc's handling
of the "noreturn" attribute associated with abort().
[cherry-picked from master]
BUG:6455193
Change-Id: I0102355f5bf20e636d3feab9d1424495f38e39e2
ARM Cortex A8 use 64 bytes and ARM Cortex A9 use 32 bytes cache line
size.
The following patch:
Adds code to adjust memcpy cache line size to match A9 cache line
size.
Adds a flag to select between 32 bytes and 64 bytes cache line
size.
Copyright (C) ST-Ericsson SA 2010
Modified neon implementation to fit Cortex A9 cache line size
Author: Henrik Smiding henrik.smiding@stericsson.com for
ST-Ericsson.
Change-Id: I8a55946bfb074e6ec0a14805ed65f73fcd0984a3
Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
By default, Android no longer compiles code using it's custom
linker script /build/core/armelf.xsc. However, this causes
problems for libc. Certain programs linked using older versions
of GOLD expect libc.so to export __exidx_start and __exidx_end.
Removing the custom linker script causes libc.so not to export
those symbols.
For now, continue using the old linker script, until we can
figure out a better solution.
Change-Id: Iaf002afd63a58b848818da24e5a4525620dc4d74
Marking segments read-only was pushing the alignment of __on_dlclose by
2 bytes making it unaligned. This change makes sure the ARM code is
aligned to the 4 byte boundary.
Bug: 6313309
Change-Id: Ic2bf475e120dd61225ec19e5d8a9a8b1d0b7f081
New functions:
tfind
tsearch
tdelete
twalk
tdestroy (GNU extension)
Bug fix: the current implementation for realpath would crash
if the second argument (resolved_path) is NULL.
New headers:
ar.h
search.h
Change-Id: Ib6c1e42fc186a6d597a6e5a9692b16acaa155804
We don't have a toolchain anymore, we don't have working original
kernel headers, and nobody is maintaining this so there is really
no point in keeping this here. Details of the patch:
- removed code paths from Android.mk files related to the SuperH
architecture ("sh")
- removed libc/arch-sh, linker/arch-sh, libc/kernel/arch-sh
- simplified libc/SYSCALLS.TXT
- simplified the scripts in libc/tools/ and libc/kernel/tools
Change-Id: I26b0e1422bdc347489e4573e2fbec0e402f75560
Signed-off-by: David 'Digit' Turner <digit@android.com>
This patch uses the new hardware feature macros for x86 to define
various compile-time macros used to make the C library use
SSE2 and/or SSSE3 optimized memory functions for target CPUs
that support these features.
Note that previously, we relied on the macros being defined by
build/core/combo/TARGET_linux-x86.mk, but this is no longer the
case.
Change-Id: Ieae5ff5284c0c839bc920953fb6b91d2f2633afc
this works by building a directed graph of acquired
pthread mutexes and making sure there are no loops in
that graph.
this feature is enabled with:
setprop debug.libc.pthread 1
when a potential deadlock is detected, a large warning is
output to the log with appropriate back traces.
currently disabled at compile-time. set PTHREAD_DEBUG_ENABLED=1
to enable.
Change-Id: I916eed2319599e8aaf8f229d3f18a8ddbec3aa8a
Use tgkill instead of tkill to implement pthread_kill.
This is safer in the event that the thread has already terminated
and its id has been reused by a different process.
Change-Id: Ied715e11d7eadeceead79f33db5e2b5722954ac9
__atomic_cmpxchg and other related atomic operations did not
provide memory barriers, which can be a problem for non-platform
code that links against them when it runs on multi-core devices.
This patch does two things to fix this:
- It modifies the existing implementation of the functions
that are exported by the C library to always provide
full memory barriers. We need to keep them exported by
the C library to prevent breaking existing application
machine code.
- It also modifies <sys/atomics.h> to only export
always-inlined versions of the functions, to ensure that
any application code compiled against the new header will
not rely on the platform version of the functions.
This ensure that said machine code will run properly on
all multi-core devices.
This is based on the GCC built-in sync primitives.
The end result should be only slightly slower than the
previous implementation.
Note that the platform code does not use these functions
at all. A previous patch completely removed their usage in
the pthread and libstdc++ code.
+ rename arch-arm/bionic/atomics_arm.S to futex_arm.S
+ rename arch-x86/bionic/atomics_x86.S to futex_x86.S
+ remove arch-x86/include/sys/atomics.h which already
provided inlined functions to the x86 platform.
Change-Id: I752a594475090cf37fa926bb38209c2175dda539
* commit '6b6ebeca985fb3843b56b507ac4ac1be44080a9c':
enable support for large files (> 2G)
Enable functional DSO object destruction
x86: Enable -fstack-protector
Update X86 Bionic CRT files for unwind/exceptions
bionic, libthread_db x86 fixes
Updated gcc 4.4.3 IA toolchain doesn't require the .ctors list
Remove an extra register move.
Replace __atomic_XXX with GCC __sync_XXX intrinsics.
move some typedefs to procfs.h required by gdbserver build
use consistent guards for off_t and size_t defines for IA
Simplify variable typing for IA builds
sigsetmask.c was not processing the "mask" argument.
Add defines for CAIF support
Remove extra/unneeded copy of fenv.h
Use proper variable typing
Update ATOM string routines to latest
Fix undefined reference to dl_iterate_phdr for x86
Fix missing NL
ptrace.c Fix source file format to unix from dos
* commit '3a13102637c8be53edf28f96598ac11aaa3e14df':
enable support for large files (> 2G)
Enable functional DSO object destruction
x86: Enable -fstack-protector
Update X86 Bionic CRT files for unwind/exceptions
bionic, libthread_db x86 fixes
Updated gcc 4.4.3 IA toolchain doesn't require the .ctors list
Remove an extra register move.
Replace __atomic_XXX with GCC __sync_XXX intrinsics.
move some typedefs to procfs.h required by gdbserver build
use consistent guards for off_t and size_t defines for IA
Simplify variable typing for IA builds
sigsetmask.c was not processing the "mask" argument.
Add defines for CAIF support
Remove extra/unneeded copy of fenv.h
Use proper variable typing
Update ATOM string routines to latest
Fix undefined reference to dl_iterate_phdr for x86
Fix missing NL
ptrace.c Fix source file format to unix from dos
Unfortunately, legacy .so files for ARM don't have a correct crtbegin file.
Consequently, we have to grandfather the old __dso_handle behaviour.
Add some ifdefs for ARM to allow it to use the old code until we can work
out a transition.
Change-Id: I6a28f368267d792c94e1d985d8344023bc632f6f
Author: H.J. Lu <hongjiu.lu@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
libcutils/mspace.c includes libc/bionic/dlmalloc.c, we need to
take care of the fact that any internal C library function cannot
be used from it.
Change-Id: I0bc81ae090b7ac2d464f26b97fc6b94a08cdad9c
The latest merge conflict resolution worked only for ARM, but not for x86
Both ARM and x86 builds have been tested with this fix.
Change-Id: I4ec1f1b0ea32fa86e7e2515b221133473d6550a3
NOTE: Care has been taken to not change the compiler flags for ARM builds.
In particular, when building crtbegin_so.so, the -fPIC flag is only
used for x86 (previous reports indicate that it breaks the ARM
build at runtime for obscure reasons).
Unfortunately, legacy .so files for ARM don't have a correct crtbegin file.
Consequently, we have to grandfather the old __dso_handle behaviour.
Add some ifdefs for ARM to allow it to use the old code until we can work
out a transition.
Change-Id: I6a28f368267d792c94e1d985d8344023bc632f6f
Author: H.J. Lu <hongjiu.lu@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Reference results of the experiments on TI OMAP3430 at 600 MHz
$ bench_strcmp -N "strcmp_1k" -s 1k -I 200
[original C code]
prc thr usecs/call samples errors cnt/samp size
strcmp_1k 1 1 10.38000 102 0 15000 1024
[ARM optimized code]
prc thr usecs/call samples errors cnt/samp size
strcmp_1k 1 1 3.08840 88 0 15000 1024
The work was derived from ARM Ltd, contributed to newlib, and reworked
for Android by Linaro.
Change-Id: Ib0d5755e1eb9adb07d80ef0252f57a5c4c57a425
Signed-off-by: Jim Huang <jserv@0xlab.org>
Added a memmove() variant for Dalvik's System.arraycopy()
implementation. It guarantees 16-bit or 32-bit atomicity depending
on the alignment of the arguments.
Bug 3398352
Change-Id: Ie7bd246305ef0ff8290513663327c5b81680368d
