{get,set}domainname aren't in POSIX but are widely-implemented
extensions.
The Linux kernel provides a setdomainname syscall but not a symmetric
getdomainname syscall, since it expects userspace to get the domain name
from uname(2).
Change-Id: I96726c242f4bb646c130b361688328b0b97269a0
Signed-off-by: Greg Hackmann <ghackmann@google.com>
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
Even though the size parameter to epoll_create(2) is (otherwise) unused,
passing in size <= 0 is explicitly documented as an error.
This change fixes the LTP epoll01 testcase.
Change-Id: I044a38be823c2fa956b57e77cc66571dfae8a4bb
Signed-off-by: Greg Hackmann <ghackmann@google.com>
The clone syscall accepts NULL child stacks, interpreting this to mean
the child gets a copy of the parent's stack with copy-on-write
semantics. However clone(2) is explicitly documented to treat this an
an error.
"Fortunately" every architecture's __bionic_clone implementation pushes
something onto the child stack before making the clone syscall. So we
know fixing this won't break legacy apps, because any app that tried
using a NULL child stack would have died with SIGSEGV.
This change fixes the LTP clone04 testcase.
Change-Id: I663b34f34bc8dad2aa405c46e4eed4418cccca0d
Signed-off-by: Greg Hackmann <ghackmann@google.com>
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
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
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
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)
Don't ask the kernel to copy data to userspace if we don't need it.
(Noticed while cleaning up sysconf to not call clock_getres.)
Change-Id: Icc0f7559775b8a2dcefe638ce831d06b75d67122
There are a hundred other reasons why we can't run on kernels old enough
to not have all the clocks covered by sysconf.
This was causing trouble for jemalloc 4.1.0 in a seccomp-constrained process
because jemalloc 4.1.0 introduced a call to sysconf that caused us to make
clock_getres syscalls for the first time, leading to SIGSYS.
Bug: http://b/27408522
Change-Id: I2eb6986d871bc03cbef278e5617734409c39e057
glibc, FreeBSD, OpenBSD, and Darwin all just leave the fd unchanged and
possibly uninitialized. Setting it to -1 seems friendlier, though.
Bug: http://b/27506278
Change-Id: I7acdc8eecbea4404d5fb4ba0b4d572245a323886
I can only assume I was testing the 32-bit implementation when I claimed
this worked. While improving the 32-bit code I realized that I'd used
signed comparisons instead of unsigned, and came back to find that the
64-bit code didn't work.
By way of apology, make x86-64 the first architecture where __memset_chk
falls through to memset.
Change-Id: I54d9eee5349b6a2abb2ce81e161fdcde09556561
Make it easier to diagnose applications mucking with the contents of
jmp_buf by checksumming its contents.
Bug: http://b/27417786
Change-Id: I9989e2ea3979a36ae0bc4c9e1bacafddbacc731b
This involves actually implementing assembler __memset_chk for arm64,
but that's easily done.
Obviously I'd like this for all architectures (and all the string functions),
but this is low-hanging fruit...
Change-Id: I70ec48c91aafd1f0feb974a2555c51611de9ef82
Also remove an if that implied that IFA_BROADCAST is a possibility for
AF_INET6.
The existing tests fail if you have a point-to-point interface configured,
so no new test necessary.
Bug: http://b/27442503
Change-Id: I4c5823b32204ae6c15527853414c2a0cef320b53
