At startup valgrind fetches the current working directory and stashes
it away to be used later (in debug messages, read config files or create
log files). But if the current working directory didn't exist (or there
was some other error getting its path) then valgrind would go in an
endless loop. This was caused by assuming that any error meant a larger
buffer needed to be created to store the cwd path (ERANGE). However
there could be other reasons calling getcwd failed.
Fix this by only looping and resizing the buffer when the error is
ERANGE. Any other error just means we cannot fetch and store the current
working directory. Fix all callers to check get_startup_wd() returns
NULL. Only abort startup if a relative path needs to be used for
user supplied relative log files. Debug messages will just show
"<NO CWD>". And skip reading any config files from the startup_wd
if it doesn't exist.
Also add a new testcase that tests executing valgrind in a deep,
inaccessible and/or non-existing directory (none/tests/nocwd.vgtest).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15989
Don't check or try to copy sigmask if it is NULL. The sigmask might be
given in a struct, where the length is non-zero, but the signal set
pointer is NULL.
Testcase provided by Paul Eggert <eggert@cs.ucla.edu>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15893
ppoll() is not POSIX, and accordingly we should ignore the lack
of support for this on OS X.
Exclude the ppoll_alarm regression test on that platform, as
introduced in r15823.
Regression test output on OS X 10.11
Before:
n/a
After:
== 602 tests, 223 stderr failures, 13 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15851
For bz#344936 procfs-non-linux.stderr.exp was renamed and split into
procfs-non-linux.stderr.exp-with-readlinkat and
procfs-non-linux.stderr.exp-without-readlinkat add both to EXTRA_DIST.
Fixes make post-regtest-checks.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15271
The VG_(extend_stack) call needs to be properly guarded because the
passed-in address is not necessarily part of an extensible stack
segment. And an extensible stack segment is the only thing that
function should have to deal with.
Previously, the function VG_(am_addr_is_in_extensible_client_stack)
was introduced to guard VG_(extend_stack) but it was not added in all
places it should have been.
Also, extending the client stack during signal delivery (in sigframe-common.c)
was simply calling VG_(extend_stack) hoping it would do the right thing.
But that was not always the case. The new testcase
none/tests/linux/pthread-stack.c exercises this (3.10.1 errors out on it).
Renamed ML_(sf_extend_stack) to ML_(sf_maybe_extend_stack) and add
proper guard logic for VG_(extend_stack).
Testcases none/tests/{amd64|x86}-linux/bug345887.c by Ivo Raisr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15138
The objective of libvex_test is to verify that the VEX lib
can be used in 'single arch mode' (host == guest).
The objective of libvexmultiarch_test is to verify that the VEX lib
can be used in 'multi arch mode' (freely choose host and guest).
(but not many combinations are working: if wordsize or endianess
differs, then libVEX quickly asserts somewhere).
libvex_test.c is somewhat bizarre, as it uses the architecture
for which we have compiled as the guest, and use a 'foreign' arch
as the host.
That allows to avoid having to define in the test a bunch
of arch specific asm instructions : the test just decode a part
of its own code, and translate it to other archs.
By default, only the combination host == guest is run.
Arguments must be given to run other combinations.
See libvex_test.c for a description on how to specify which combinations
to run.
LibVEX host != guest does not (yet?) work when endianess or word size differs
between host and guest.
Also, currently, TILEGX host is not working properly (unless guest is also
TILEGX), as the evcheck instructions generated differs according to
the offset of the host_EvC_{FAILADDR,COUNTER}.
So, using TILEGX as host is only done when guest is also TILEGX.
Note that it is possible to specify a specific host arch to use.
For example, to force TILEGX to be used, do:
./none/tests/libvexmultiarch_test 1034
(where 1034 is the decimal value corresponding to the enum VexArchTILEGX.
This currently aborts with:
...
------------------------ Assembly ------------------------
EvCheck (evCheck) ld r11, 8(r50); addli r11, r11, -1; st r11, 8(r50); bgez r11, nofail; jalr *(r50); nofail:
vex: priv/host_tilegx_defs.c:2353 (emit_TILEGXInstr): Assertion `evCheckSzB_TILEGX() == (UChar*)p - (UChar*)p0' failed.
//// failure exit called by libVEX
Whe TILEGX is fixed, we can remove the specific condition that avoids using
TILEGX as host.
Small changes have been done on VEX to allow more combinations
to work:
* host_mips_defs.c : when not compiled on mips,
a lot of mips specific code is not compiled at all, because
one of _MIPSEL or _MIPSEB must be defined to have either the
little endian code or big endian code.
emit32 function must however work to use mips as host.
So, for this function, if _MIPSEL is not defined, then
the big endian code is compiled in by default.
(the mips endianess should probably be handled like the ppc
endianess, for which the endianness to use is decided at runtime).
* host_arm64_isel.c : addition of a 'do not emit anything' for
ABI HINT (avoid an assert e.g. for amd64 guest, arm64 host)
* libvex_guest_amd64.h : when I was still hoping mixing amd64 and x86,
a first assert was firing up due to size/alignment
of VexGuestAMD64State when compiled in 32 bits.
=> addition of pad elements to ensure the size and alignment
of VexGuestAMD64State stays the same when compiled in 32 and
64 bits (the 64 bits layout is unchanged).
The new tests have been run on x86/amd64/ppc64/s390x.
It is very well possible that the tests will fail on untested archs
(ppc32 or mips* or arm* or tilegx)
(e.g. because the hardcoded hwcaps in libvex_test.c are not ok).
It should be relatively trivial to fix these hwcaps problems.
Some other problems might be less easy to understand and fix
(e.g. similar to the TILEGX evcheck or mips emit32 problem).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15084
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
To do that a small enhancement to vg_regtest was needed:
(1) New declaration to allow specifying an environemnt variable
that is set prior to invoking valgrind.
eg: env: VAR=VAL
There can be more than one such declaration
(2) prog-asis: program_name
This is like prog: except the program name is not prefixed with
the testdir.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15064
VG_(debugLog_vprintf).
Remove function VG_(percentify) and fix up its call sites (part of
fixing BZ #337869.
Allow the width in a format specification to be '*', i.e. the width is
given as an additional function argument.
The limitations for printing floating point numbers are:
(1) %f is the only supported format. Width and precision can be
specified.
(2) Funny numbers (NaN and such) are not supported.
(3) Floating point numbers need to be benign in the sense that their
integral part fits into an ULong.
This is good enough for our purposes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14806
To implement QGetTlsAddr, gdbsrv has to know how to get the glibc dtv
address and the module id from the link_map.
These 2 things are dependent on the internals of glibc.
The dependency is mostly isolated in a few lines of arch dependent
code or in an external utility that used a hack + -ldl lib to find
the offset of the modid in the link_map structure.
Tested on x86/amd64/ppc64/s390x. Somewhat tested on ppc32 and arm64.
Untested/a few #ifdef-ed lines not compiled on arm/mips32/mips64
and darwin.
For more background info about thread local storage handling, see
'ELF Handling For Thread-Local Storage' http://www.akkadia.org/drepper/tls.pdf
Changes:
* auxprogs/getoff.c new auxilliary program to get platform specific offsets
(currently only the offset for the module id in struct link_map).
* configure.ac : check for dlinfo(RTLD_DI_TLS_MODID) needed for getoff.c
* new gdbserver_tests/hgtls, testing various types of __thread variables
* various m_gdbserver files:
- implement decoding of the QGetTlsAddr query
- for each platform: platform specific code to get the dtv
- call to external program getoff-<platform> the first time an
__thread variable is printed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14283
MIPS has different signal values, so it has to have its own expected output for
the tests that deal with signal values.
This fixes (false) failure in none/tests/async-sigs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12791
errno codes in asm-generic/errno-base.h (on linux).
The error strings were obtained by calling strerror natively in
Linux.
Extend vki-linux.h accordingly. vki-darwin.h already had
those errno codes.
Add testcase. This fixes#287858.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12316
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
(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
that specified shared objects contain specified symbols. Along with a
couple of regtests that unfortunately will fail on MacOSX.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11125
