Older gcc (4.8) default to GNU C90. Causing:
dlclose_leak.c:14:5: error: ‘for’ loop initial declarations are only
allowed in C99 mode
Fix by declaring int i before the loop.
As reported by Matthias Schwarzott <zzam@gentoo.org>. Testcase patch from him. The fix is
for check_CFSI_related_invariants() to avoid checking for overlaps against DebugInfos that are
in 'archived' status, since -- if a previously dlopened-and-then-dlclosed object is later
re-dlopened -- this may cause an overlap between the active and archived DebugInfos, which
is of no consequence. If the kernel maps the object to the same VMA the second time around
then there will *certainly* be an overlap.
(from bug 385408 comment 0):
Valgrind currently lacks support for the z/Architecture vector "support"
instructions introduced with z13. These are documented in the
z/Architecture Principles of Operation, Eleventh Edition (March, 2015),
chapter 21: "Vector Overview and Support Instructions".
Bug 387664 changes the default settings for accurate definedness checking
for {Add,Sub}{32,64} and {CmpEQ,CmpNE}{8,16,32,64}. This fix updates the
vbit tester (memcheck/tests/vbit-test) to test the accurate versions of
these, and thereby fixes a regression caused by
e847cb5429 as committed for bug 387664.
Memcheck reports an error on "if (n == 42)" in this test. Unless, that is,
accurate CmpEQ/NE definedness tracking is enabled. If you stare at this
long enough it is possible to see that the test "n == 42" isn't actually
undefined, because |n| is only ever zero or one, and only its least
significant bit is undefined. So the equality comparison against 42 is
defined because there are corresponding bits in the two operands that are
different and are both defined.
This commit fixes that by comparing with 1, which forces the result to
really depend on the only undefined bit in |n|.
I also added robustification:
* return arbitrary values from gcc_cant_inline_me(), so as to avoid gcc
simply copying the input to the output or otherwise deleting the
conditional branch.
* marking gcc_cant_inline_me() as un-inlineable
* Putting compiler barriers in the second conditional in main(), so gcc
can't simply ignore the result of the call to gcc_cant_inline_me() and
then delete the call entirely.
New Iops are defined:
Iop_Scale2_32Fx4, Iop_Scale2_64Fx2,
Iop_Log2_32Fx4, Iop_Log2_64Fx2,
Iop_F32x4_2toQ16x8, Iop_F64x2_2toQ32x4,
Iop_PackOddLanes8x16, Iop_PackEvenLanes8x16,
Iop_PackOddLanes16x8, Iop_PackEvenLanes16x8,
Iop_PackOddLanes32x4, Iop_PackEvenLanes32x4.
Contributed by:
Tamara Vlahovic, Aleksandar Rikalo and Aleksandra Karadzic.
Related BZ issue - #382563.
The bug itself was solved in 3.12 by the addition of __gnu_cxx::__freeres
in the libstdc++ and have valgrind calling it before exit.
However, depending on the version of the libstdc++, the test leak_cpp_interior
was giving different results.
This commit adds some filtering specific to the test, so as to not depend
anymore of the absolute number of bytes leaked, and adds a suppression entry to
ignore the memory allocated by libstdc++.
This allows to have only 2 .exp files, instead of 4 (or worse, if
we would have to handle yet other .exp files depending on the libstdc++
version).
Previous implementation misused some opcodes, and a side effect was
dead code emission.
To reimplement handling of these instructions, three new IoPs have been
introduced:
Iop_DivModU64to64, // :: I64,I64 -> I128
// of which lo half is div and hi half is mod
Iop_DivModS32to32, // :: I32,I32 -> I64
// of which lo half is div and hi half is mod
Iop_DivModU32to32, // :: I32,I32 -> I64
// of which lo half is div and hi half is mod
Patch by Aleksandra Karadzic and Tamara Vlahovic.
According to the epoll_pwait(2) man page:
The sigmask argument may be specified as NULL, in which case
epoll_pwait() is equivalent to epoll_wait().
But doing that under valgrind gives:
==13887== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s)
==13887== at 0x4F2B940: epoll_pwait (epoll_pwait.c:43)
==13887== by 0x400ADE: main (syscalls-2007.c:89)
==13887== Address 0x0 is not stack'd, malloc'd or (recently) free'd
This is because the sys_epoll_pwait wrapper has:
if (ARG4)
PRE_MEM_READ( "epoll_pwait(sigmask)", ARG5, sizeof(vki_sigset_t) );
Which looks like a typo (ARG4 is timeout and ARG5 is sigmask).
This shows up with newer glibc which translates an epoll_wait call into
an epoll_pwait call with NULL sigmask.
Fix typo and add a testcase.
https://bugs.kde.org/show_bug.cgi?id=381289
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16451
Use .set noat directive to prevent assembler from complaining about
subsequent instructions that use register $at.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16400
mempool2 test was using a wrong address for the pool arguments
in the client requests VALGRIND_MEMPOOL_FREE.
So, instead of testing what it was supposed to test (e.g. reading
memory from a freed mempool block), this was all causing
an illegal memory pool address.
So, fix the calls, and add a specific test to verify the illegal
mempool address.
(detected while looking at bug 375415)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16369
Exception specifications are a deprecated feature in C++11 and gcc 7
complains about these specifications. Hence remove these specifications.
This patch avoids that gcc reports the following:
warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16360
Compiler produces position independent executables (PIE) by default
which gets in the way of some unit tests.
Fixes BZ#377066.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16349
and FUTEX_WAKE_BITSET, check only 4 args for FUTEX_WAKE_BITSET,
and 2 args for FUTEX_TRYLOCK_PI.
Fixes BZ#377698.
Patch by: diane.meirowitz@oracle.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16285
Increase the size of allocated array, so mprotect call does not end up
protecting non-allocated areas. This enables the test to work on
platforms with pagesize=64K.
Issue discovered on MIPS XLP machine with 64K pagesize.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16220
This patch forces leak_cpp_interior to be compiled using old implementation
of std::string.
Related issue #373069
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16217
This should fix issue with sendmsg test and glibc 2.22.
Glibc 2.22 introduced sysdeps/unix/sysv/linux/sendmsg.c that has
__libc_sendmsg function implementation (in comparison to earlier
implementation in syscall-template.S).
So, test suite needs to filter out this case, otherwise we get test
diffs such as:
Syscall param sendmsg(msg) points to uninitialised byte(s)
- at 0x........: sendmsg (in /...libc...)
+ at 0x........: sendmsg (sendmsg.c:28)
which are false positives.
This fixes memcheck/tests/sendmsg (stderr) on platforms with 2.22+ glibc.
Patch by Aleksandra Karadzic.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16213
Motivation for this change is similar to what has already been done in other
leak-* tests. That is, call CLEAR_CALLER_SAVED_REGS (currently used only on
PPC and MIPS arches) to clear temporary registers that might be holding
pointers lost in a previously called function.
This fixes memcheck/tests/leak-tree failure on some MIPS platforms.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16173
