to let the user specify a max nr of loss records to output : on huge
applications, interactive display of a lot of records in gdb can
take a lot of time.
* mc_include.h :
- added UInt max_loss_records_output; to LeakCheckParams structure
- avoid passing LeakCheckParams by struct copy.
* modified test gdbserver_tests/mcleak to test the new parameter
* mc_main.c : parse or set max_loss_records_output in leak_check cmd
handling and calls.
* mc-manual.xml : document new leak_check parameter
* mc_leakcheck.c :
- extract printing rules logic in its own function
- in print_results, if there is a limit in LeakCheckParam,
compute from where the printing of loss records has to start
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12329
other wrappers in that it took place before the silly-args check.
Testcase and patch by Yann Droneaud (yann@droneaud.fr).
Fixes#281482
Also included is a related fix to MC_(new_block). Incrementing the
alloc counter and updating the allocated memory amount should
occur under the same condition (allocation succeeded).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12324
* move memcheck/perf/many-loss-records test to perf directory
massif/perf/many-xpts test to perf directory
* modified many-loss-records.vgperf and many-xpts.vgperf,
so as to have tool specific options prefixed with their tool
* remove directory memcheck/perf and massif/perf (containing no test anymore)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12315
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
* initial support for Pandaboard/Linaro
* on Android/ARM, ask for non-executable stacks in the executables
* disable Memcheck's strcasestr intercept; its use of tolower()
causes the dynamic linker to fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12234
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
narrowing operations. The previous scheme was simply wrong and could
cause false negatives, by causing some narrowing operations to have a
defined output even when the inputs are undefined. This was what
#279698 reported. This patch is a fix for that bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12190
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
VALGRIND_ENABLE_ERROR_REPORTING, VALGRIND_DO_ADDED_LEAK_CHECK,
VALGRIND_DO_CHANGED_LEAK_CHECK macros causes gcc 4.6 to print
a warning message about assigning a value to an unused variable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12110
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
* configure.in support
* new supp file darwin11.supp
* comment out many intercepts in mc_replace_strmem.c and
vg_replace_malloc.c that are apparently unnecessary for Darwin
* add minimal handling for the following new syscalls and mach traps:
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
* wqthread_hijack on amd64-darwin: deal with
tst->os_state.pthread having an apparently different offset,
which caused an assertion failure
* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
cleanup added in r12041/12042 to handle apparently new dyld
behaviour, which is to map text areas r-- first and only
vm_protect them later to r-x.
The following cleanups remain to be done
* remove apparently pointless, commented out wrapper macro
invokations in mc_replace_strmem.c, eg
//MEMMOVE(VG_Z_DYLD, memmove)
(or determine that they are still necessary, and uncomment)
* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
there
* write proper syscall wrappers for
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
These are currently just no-ops and may be causing Memcheck to
report false undef-value errors
* figure out why it doesn't work properly unless built with gcc-4.2 on
Lion.
gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1). Plain
gcc is the hybrid gcc-front-end clang-back-end thing
(i686-apple-darwin11-llvm-gcc-4.2). Whereas on Snow Leopard, plain
gcc is the normal gcc.
The symptoms of the failure are that wqthread_hijack in
syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
at the end (you need a pretty complex threaded app to trigger this),
which makes me think that either ML_(wqthread_continue_NORETURN) or
call_on_new_stack_0_1 do return, which they are not expected to.
* figure out if some of the uninitialised value errors reported in
system libraries on are caused by Memcheck being confused by LLVM
generated code, as per bug #242137
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043
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
* move MEMCPY(NONE, ZuintelZufastZumemcpy) to the correct ifdef;
it got put in the wrong place by r12009 a couple of hours ago.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12010
the Linux and Darwin definitions so they are in completely separate
ifdefs -- iow, remove any definitions that are common to both. This
gives some duplication, but the upside is that it is now possible to
edit the Darwin intercepts without fear of breaking the Linux ones.
This will be important when it comes to supporting OSX 10.7.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12009
where it otherwise wouldn be. On x86-linux running Memcheck, gives a
6% instruction count reduction and a 10% reduction in memory traffic.
(Duh!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11998
