This speeds up the debug malloc code by using the original unwinding code.
The only catch is that it has to link in the libc++ arm unwind code or
there will be crashes when attempting to unwind through libc++ compiled
code.
Bug: 16874447
(cherry picked from commit 3f7635f4906c53fa744731efc35235456b7d93bf)
Change-Id: If8a3821cdd95ed481bb496bf2daab449d13790f8
* commit '388369b788f93670551fe32233b6c4b55d3879d9':
call uselocale() before freelocale() to make sure that g_local_key has a valid locale.
Switch to OpenBSD <err.h> implementation.
For tests that call uselocale(), the locale is stored in the
g_userlocale_key thread-specific key. If freelocale() is called later,
then g_uselocal_key points to a deleted pointer. CTS eventually calls
vfprintf to print the result, which calls MB_CUR_MAX and MB_CUR_MAX
accesses the deleted locale stored in g_uselocale_key, causing unpredictable
errors.
Fixed the tests by calling uselocale() with the old locale before
calling freelocale.
(cherry-pick of 8a46cf0fcf82b8c76e05be7e066ec854f974603a.)
Bug: 17299565
Change-Id: I87efa2a9b16999a11d587f68d3aeedcbe6ac8a2c
For tests that call uselocale(), the locale is stored in the
g_userlocale_key thread-specific key. If freelocale() is called later,
then g_uselocal_key points to a deleted pointer. CTS eventually calls
vfprintf to print the result, which calls MB_CUR_MAX and MB_CUR_MAX
accesses the deleted locale stored in g_uselocale_key, causing unpredictable
errors.
Fixed the tests by calling uselocale() with the old locale before
calling freelocale.
Bug: 17299565
Change-Id: I87efa2a9b16999a11d587f68d3aeedcbe6ac8a2c
This speeds up the debug malloc code by using the original unwinding code.
The only catch is that it has to link in the libc++ arm unwind code or
there will be crashes when attempting to unwind through libc++ compiled
code.
Bug: 16874447
Change-Id: Ifdbbcbd4137d668b25cf3c2bd59535e06ebfa5a7
Stdatomic.h was potentially redefining _Atomic, in spite of a
prior definition by <atomic>. This could cause g++ builds that
included <stdatomic.h> with an available <atomic> header to break.
Change-Id: I562c7115118c0587d594d4d5b62d25101e47bfd8
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
(cherry picked from commit 57b7a6110e7e8b446fc23cce4765ff625ee0a105)
Change-Id: I87e679ee1c0db8092f2d1221c8e7c1461545c5a4
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Change-Id: I1d4dbffe7bc7bda1d353c3a295dbf68d29f63158
