rev 12001 has introduced a regression in VG_(env_remove_valgrind_env_stuff):
to avoid modifying a possibly read-only env string, the string is duplicated,
and the copy is modified. However, mash_env_column modifies the string
"in-place". The modified string was not put back in the env (and could not,
because the src string is only partially copied).
This means that the valgrind preload strings were not cleaned up and
when a 32 bit executable execs a 64 bits (or vice versa: 64 bit execs 32 bits),
LD_PRELOAD contains both the 32 bits and 64 bits versions of Valgrind
vgpreload.... => ld.so then gives an error msg, as it can't preload either
the 32 or the 64 bits version.
The patch fixes this by duplicating the whole env string, and passing
to mash_colon_env a pointer to the correct offset in the whole env string.
The duplicated string is replacing the original entry in envp.
This patch adds two regression tests : none/tests/allexec32 and
none/tests/allexec64. On a bi-arch valgrind, these will be 32bits and 64 bits
executables, exec-ing each other. On a single arch, one will be a symlink
to the other (to avoid different .exp files, and still test exec).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12287
is set. This ensures a correct help msg is given when
the valgrind installation is moved, and VALGRIND_LIB is
then set to the new valgrind lib location.
Note it does not improve the help msg when valgrind
is run "in place" (e.g. when using vg-in-place).
(Patch from Paul Pluzhnikov).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12278
specified, the handler returns to the previous context rather than to
whatever value happens to be parked in the link register (duh).
Previous behaviour made complete nonsense of signal returning on
Android.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12273
So, replace the code which counts the nr of bits in the level0
bitmap by just returning the nr of elements in use.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12272
* 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
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
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
and use read_Type routines instead as they work rather better on strict
aligned (or semi-strict a la ARM) machines. Fixes#282527.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12083
Those are obtained by looking at some commonly defined environment
variables.
That should help with problems where /tmp is shared or process IDs get
recycled. We had some intermittent nightly build issues because of that.
Partial fix for bugzilla #280757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12071
VG_MINIMAL_SETJMP and VG_MINIMAL_LONGJMP introduced in r12067.
With this commit, it should be possible to build a working 64 bit
Valgrind using the default gcc as supplied with Xcode 4.1 on OSX 10.7.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12070
VG_MINIMAL_LONGJMP directly, rather than using __builtin_setjmp
and __builtin_longjmp, since clang-2.9 miscompiles the latter
(by completely ignoring it.)
Also, add comment about the return type for VG_MINIMAL_SETJMP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12067
and TMPDIR which was introduced when fixing bugzilla #267020.
Factor out VG_(tmpdir). New function VG_(vgdb_path_prefix).
Partially fixes bugzilla #280757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12063
