At least one of the compilers for s390x nightly builds was inlining it.
Update exp files accoordingly. This should fix any residual back-trace
noise for this testcase.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12235
memcheck.h) by changing a bunch of VALGRIND_DO_CLIENT_REQUEST_EXPR
into VALGRIND_DO_CLIENT_REQUEST_STMT for cases where the return value
of the former would be unused. (Bart Van Assche, bart.vanassche@gmail.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12226
that if the range is partially non-addressable and it contains
undefined data, both errors are reported.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12222
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
This patch provides three improvements in the way the free list is
handled in memcheck.
First improvement: a new command line option --freelist-big-blocks
(default 1000000) specifies the size of "free list big blocks".
Such big blocks will be put on the free list, but will be re-cycled first
(i.e. in preference to block having a smaller size).
This fixes the bug https://bugs.kde.org/show_bug.cgi?id=250065.
Technically, the freed list is divided in two lists : small
and big blocks. Blocks are first released from the big block list.
Second improvement: the blocks of the freed list are re-cycled before
a new block is malloc-ed, not after a block is freed.
This gives better error messages for dangling pointer errors
when doing many frees without doing malloc between the frees.
(this does not uses more memory).
Third improvement: a block bigger than the free list volume will be
put in the free list (till a malloc is done, so as the needed memory
is not bigger than before) but will be put at the beginning of the
free list, rather than at the end. So, allocating then freeing such a
block does not cause any blocks in the free list to be released.
Results of the improvements above, with the new regression test
memcheck/test/big_blocks_freed_list: with the patch, 7 errors
are detected, 6 are giving the (correct) allocation stack.
Without the patch, only 6 errors are detected, 5 errors without
allocation stack, 1 with a (wrong) allocation stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12202
the tarball generated by "make dist".
With this change running regtest from the tarball produces the same
results as a regtest on a checked out repository (on x86 that is).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12172
must come first before the filename gets changed to bogus.S
This should unbreak the failure on x86_64. But I can't test it.
We shall see.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12099
Promote the s390x exp file to be the golden one because it has the
correct result. Add an exp-kfail file for those platforms where the testcase
fails (x86).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12098
same line for all architectures.
Promote the s390x exp file to be the golden one because it has the
correct result. Add exp-kfail files for those platforms where the testcases
fail (x86).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12097
First, due to a typo in Makefile.am it was compiled with the wrong flags.
Secondly, the testcase gives an incorrect backtrace on x86 (missing the
line where the error occurs). Updated the generic exp to contain the
correct result and added exp-kfail for platforms where this test fails.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12094
a file name writev.c. This screws our filename based backtrace
filtering. Rename writev to writev1 to avoid that problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12093
they produce an incomplete backtrace. Added exp-kfail files to capture the
results with the incomplete backtraces. Updated the generic exp files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12092
and update exp files accordingly. This works well for x86
and all testcases pass on my machine.
New file filter_memcheck to do the work.
There is a bit of a ripple here as filter_memcheck requires
command line arguments to be passed in. So all users of
filter_memcheck (direct or indirect) were updated as well.
filter_stderr was simplified as was filter_libc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12091
The reason is that the point of failure is in glibc
in a file named execve.c The backtrace filtering
(which is filename based) cannot distinguish the
two execve.c file names. Renaming the testcsae does the
trick.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12090
* when creating threads, just ask for a 256k stack size, since creating
498 threads each with the default 8M stack size fails on 32 bit machines.
* limit number of callers to 3 so as to remove junk frames that cause
different output on 32 vs 64 bit targets.
* add a proper self-check at the end, to verify the number of detected errors
is as expected
* update output accordingly
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12086
This is due to older versions of GCC who use the MVC insn for
assignments and that creates a sequence of 1-byte memory accesses.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12026
The testcase was executed despite uname -r being 2.6.9-42.EL
Extend tests/os_test.c to take an optional 2nd argument
which is a minimum version number. Use os_test in the
prerequisite expression.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11954
VALGRIND_{DISABLE,ENABLE}_ERROR_REPORTING, which allow a thread to
temporarily disable reporting of errors it makes. This is useful for
making Memcheck behave sanely in the presence of some MPI
implementations. Also mark up libmpiwrap.c accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11910
swapping the roles of the VALGRIND_DO_CLIENT_REQUEST() and
VALGRIND_DO_CLIENT_REQUEST_EXPR() macros. Also, many __attribute__((unused))
declarations on variables have been eliminated. Closes#269778.
Note: so far this patch has been tested on x86/Linux, amd64/Linux and
ppc64/Linux but not yet on any other supported CPU/OS combination.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11755
