The stack offsets assumed we'd pushed %ebx. Unlike x86-64 we can't fall
through, but we can avoid repeating work we've already done.
Change-Id: I7e5f9be50983ed6178dd0c0534042da7ea30ad0c
Caused build breakage, but not spotted by TreeHugger:
external/libnfc-nxp/Linux_x86/phDal4Nfc.c:737:5: error: implicit declaration of function 'pthread_setname_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pthread_setname_np(pthread_self(), "reader");
^
Nice file name.
Change-Id: I102e55718babf4e4f2f2c64066c6a83ed3ac86d3
Also guard both these GNU extensions with _GNU_SOURCE.
Also improve the tests to test each case on both the current thread and
another thread, since the code paths are totally different.
Bug: http://b/27810459
Change-Id: I72b05bca5c5b6ca8ba4585b8edfb716a1c252f92
pthread_barrier_smoke test uses WaitUntilThreadSleep() to wait until
BarrierTestHelper threads sleep in pthread_barrier_wait(). But this
is flaky as there a two futex_wait places in pthread_barrier_wait.
This patch modifies this test to avoid using WaitUntilThreadSleep().
Bug: 27780937
Change-Id: I4c36b82cce9345d5088f8854b289dc5bf7a08e8c
The free track mechanism could fail if, at the same time a free occurs,
another thread is trying to free and verify the same allocation. This
doesn't work if the freed allocation is added to the list and we still
do work on it. The fix is to only add to the free list when we are done
with the allocation.
Also fix a problem where the usable size is computed incorrectly because
two of the arguments where reversed.
In addition, add a check that the allocation being verified has the correct
tag before trying to check the body of the allocation.
Add a test to catch the original failure.
Add a test for the tag being different.
Bug: 27601650
Change-Id: Ie9200677d066255b8e668a48422f23f909f4ddee
We don't have a compile-time limit on the number of threads,
and we don't have a definite run-time limit either.
Bug: http://b/27617302
Change-Id: I6a6fe083e7b655d24eb9e7ef7f3e0280d483080b
We still use GCC to build the bionic unit tests into CTS, and it emits a
false positive -Wmissing-field-initializers warning for the C++11 aggregate
initialization syntax `Foo foo = {}`.
Bug: http://b/27656293
Change-Id: I016d8dae6d6cd28afe4bc19250c2a8fba908f8e6
If the first option is found, then any unknown options are simply
ignored, but do not produce an error. Fixed this so that each
option found is actually verified to exist.
Bug: 27620263
Change-Id: If58732df3285eeae72188162c505e0e202fada8c
FreeBSD doesn't seem interested in having low-quality implementations of
these functions:
cacoshl, cacosl, casinhl, casinl, catanhl, catanl, ccoshl, ccosl, cexpl,
clog, clogf, clogl, cpow, cpowf, cpowl, csinhl, csinl, ctanhl, ctanl.
And they still haven't got round to writing good implementations, so for
now let's just take the NetBSD ones so we have the full set.
Bug: http://b/27555792
Change-Id: I6b72003cf749b1043f006377a01fffe5e1d659bc
Do not initialize all of the global function pointers associated with
debug malloc until the initialization has completed correctly.
Bug: 27600760
Change-Id: I0621b54bc2d9fab63805d7992d384e550d6fed2a
The over flow check for nmemb * bytes in debug_calloc is incorrect,
use the builtin overflow functions to check for multiplication and
addition overflow.
Change-Id: I3f1c13102621bc5380be1f69caa88dba2118f3cb
(cherry picked from commit 239838608d)
0 byte allocations can cause problems if they are immediately followed
by another allocation with no header, as both allocations will have the
same address. Treat 0 byte allocations as 1 byte allocations so that
debug_iterate will return separate addresses for them.
Bug: 27578580
Change-Id: Ia8dc3481fa7062391e9b3ae58a36e8d47e7ee557
(cherry picked from commit 15af478080)
malloc_iterate with malloc debug enabled was returning allocation sizes
using the requested size instead of usable size. If anything wrote
pointers above the requested size but below the usable size, those
pointers would be invisible to libmemunreachable and referenced
allocations could be reported as a leak.
Bug: 27107100
Change-Id: I6b19fd631f68ce93b3aee408cc3d296ec457bd01
(cherry picked from commit b23c6606d2)
When using libhoudini to run arm code on x86 platforms, we can't
assume the main thread allocates local variables at the stack
declared by kernel.
Change-Id: Id9457f47fc338a3103fdee25a7a6e622915e7090
The previous code assumed that returning would be sufficient to rethrow
signals like SIGSEGV. This is not true, for example, in the case where a
SIGSEGV is sent via kill(2). We were previously only sending the signal
to ourselves in some cases, because using kill(2) would lose information
in the siginfo_t argument. Use rt_tgsigqueueinfo(2) instead to preserve
its contents.
Bug: http://b/27367422
Change-Id: I1be822818d5905461979c7e12dc4e9c25049273b
Elliott Hughes
Greg Hackmann
Yabin Cui
Christopher Ferris
Douglas Leung
Dan Willemsen
Josh Gao
Colin Cross
Erik Kline
jzha136