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
the mknod operations fail. It can still be used if you can get past
that point, but you need an explicit --vgdb=yes for the time being.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12233
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
(Rusty Russell, rusty@rustcorp.com.au)
tdb uses fcntl locks and mmap, and some of the tests fail under valgrind.
strace showed valgrind opening the tdb file, reading 1024 bytes, then closing
it. This is not allowed: POSIX says if you open and close a file, all fcntl
locks on it are dropped (insane, yes).
Finally got around to hacking the source to track this down: di_notify_mmap is
doing the damage. The simplest fix was to hand in an optional fd for it to
use, then have it do pread.
I had to fix your pread; surely this should seek back even if the platform
doesn't have pread support?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12224
* fix various typos in doc
* following commit in gdb
http://sourceware.org/ml/gdb-patches/2011-07/msg00742.html
means unlimited length for valgrind watchpoints is understood by the
(future) gdb 7.4 => doc updated
* factorize gdb version detection and reporting in
gdbserver_tests/make_local_links
* replace zignal by signal in a string used in umsg.
* updated gdbserver_tests/README_DEVELOPPERS (ref to --port vgdb option)
No functional change, tested on f12/x86, debian5/amd64, s390/RHEL4
Fixes#278892. (Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12223
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
Monitor command useful for debugging/investigation of Valgrind unwinder and/or
gdbserver/gdb stack trace.
The Valgrind unwinder has some limitations compared to the GDB unwinder.
(see e.g. 278972).
With this monitor command, it is easy to see if the Valgrind unwinder
produces something different than the GDB unwinder.
Fixes#279212. (Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12203
(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
quadratic growth on some apparently simple test cases. Fixes#267925.
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12201
libtool has not been installed:
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12198
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
- Replaced AC_CONFIG_HEADER() by AC_CONFIG_HEADERS().
- Replaced AC_TRY_LINK() by AC_LINK_IFELSE().
- Replaced AC_TRY_COMPILE() by AC_COMPILE_IFELSE().
- Removed AC_TYPE_SIGNAL because RETSIGTYPE isn't used anywhere.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12189
present that doesn't happen. #272967, which is Debian bug 599563.
(Pierre Habouzit, madcoder@debian.org)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12186
print the object and SVMA too, so as to make it easy to find the
relevant bit of code by objdump -d of the object, even if the
function name is unknown. Also re-order some of the fields.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12184
