The original fix in svn r15793 read argument 6 separately by using PRA6
unconditionally. This is wrong. We need to first check whether a
track_pre_reg_read callback is registered (only memcheck does).
The PRE_REG_READX macro already had this check. Just add the same
before calling PRA6. Thanks to Tom Hughes for noticing. Without this
helgrind/tests/cond_timedwait_test and drd/tests/pth_inconsistent_cond_wait
regtests would fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15795
Same kind of problems as explained and fixed in revision 15720:
In some cases, unwinding always retrieves the same pc/sp/bp.
Fix for 64 bits is similar: stop unwinding if the previous sp is >= new sp
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15794
for auditon(2) subcode of the auditsys() syscall
were removed in Solaris 12.
However they stay for Solaris 11 and illumos.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15791
VEX commit 3209 fixed: an issue with caculating the carry to the next 32-bit
chunk for the Power PPC 128-bit add and subract instructions: vaddcuq, vadduqm,
vsubcuq, vsubuqm, vaddecuq, vaddeuqm, vsubecuq, vsubeuqm
The corresponding test case didn't catch the issue. This commit adds data
values to the test that verify the issue is fixed.
Valgrind Bugzilla 359472
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15790
When the elt to allocate is bigger than the pool size, allocate
a specific pool only for this element.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15787
largefile support by default. This gets in the way what
Valgrind core expects (vki, various m_libc modules).
Therefore disable largefile support if it is enabled.
Anyway, support for 32-bit applications is going away in Solaris 12.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15785
Solaris 12 transitioned to public libproc and mdb now prints
'raw lwps' instead of 'native threads' for the threading model.
This information is irrelevant for coredump generation and analysis;
therefore leave it out.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15783
We have to explicitly test command -v host worked otherwise on systems
that do not have 'host' installed will return error code 127 and stop
testing. This is because vg_regtest uses '/bin/sh -c' to execute the
prereq command. Found by Petar Jovanovic.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15781
* Complain instead of asserting when negative line nr in inline info
* use a macro to factorise the complain once logic about lineno limits
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15780
The MIPS64 getdents64() system call is only present in 3.10+ kernels.
If the getdents64() system call is not available fall back to using
getdents() and modify the result to be compatible with getdents64().
This matters only when --track-fds=yes is set.
This change fixes none/tests/fdleak* failures on MIPS64 platforms with
kernel versions older than 3.10.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15778
At many places, we have:
VG_(fun(a,b,c))
instead of
VG_(fun)(a,b,c)
So, fix these cases, found using:
grep -n -i -e 'VG_([a-z][a-z0-9_]*[^a-z0-9_)]' *.c */*.c */*/*.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15776
C++ allocator from Solaris Studio allocates for std::string
57 bytes instead of former 40 bytes on 64-bit, and 45 bytes instead of 28 on 32-bit.
Confirmed with truss and --trace-alloc=yes.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15775
tinycc.c: In function ‘expr_eq’:
tinycc.c:13368:21: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
gv(rc);
^~
tinycc.c:13366:17: note: ...this ‘else’ clause, but it is not
else
^~~~
Two statements are indeed misleadingly indented. Fixed by unindenting them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15772
ccache sometimes causes the source file absolute name to be another
full path (not $PWD).
This means that the badfree3 and varinfo5 tests can fail due to
the full path after not being match on $PWD.
So, rather ask full path after a part of the path that is stable
even when ccache decides to reuse a already compiled object from
another directory.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15771
v6media.c: In function ‘gen_cin’:
v6media.c:10:12: warning: type of ‘cin’ defaults to ‘int’ [-Wimplicit-int]
static int gen_cin(cin)
Just make the argument an int.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15769
glibc 2.20 deprecated _BSD_SOURCE and _SVID_SOURCE and now requires
_DEFAULT_SOURCE to be defined instead. Add _DEFAULT_SOURCE define to
prevent warnings like:
In file included from /usr/include/stdio.h:27:0,
from stack_switch.c:5:
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
See https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15768
We wrap some deprecated things in libmpiwrap. Since we do want to keep
wrapping those add -Wno-deprecated-declarations to squash warnings like:
libmpiwrap.c:281:4: warning: ‘ompi_mpi_ub’ is deprecated: MPI_UB is deprecated in MPI-2.0 [-Wdeprecated-declarations]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15767
We used to set the process datasize rlimit to zero to prevent
any internal use of brk() from having any effect. But later
linux kernels redefine RLIMIT_DATA as the size of any data
areas, including some dynamic mmap memory allocations.
See bug #357833 for the commit that went into linux 4.5
changing the definition of RLIMIT_DATA. So don't mess with
RLIMIT_DATA anymore. Just remember it for use in the syscall
wrappers.
This also cleans up some hacks around the execv and spawn wrappers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15766
"command -v" is a (POSIX) shell builtin that should work everywhere.
"which" might be an external command that might not be installed in
which case the shell might just error out.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15765
slot to 1. Rather do that in add_segment which is where the segment
refering to that name actually comes into existence.
Properly handle the case in add_segment where the to-be-added segment
and one (or more) of the segments it replaces have the same name
This may occur when doing a mremap.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15761
aspace mgr provides VG_(am_mmap_client_heap) that mmaps memory and
marks it as being client heap memory. Marking superblock segments used
for malloc/free as heap is critical for correct leak search: segments
mmap-ed for malloc/free cannot be considered as part of the root set.
On the other hand, other mmap-ed segments cannot be marked as client
heap, otherwise these segments will not be part of the root set, and
will not be scanned.
aspacemgr merges adjacent segments when they have the same characteristics
e.g. kind, RWX and isCH (is client heap) must be the same (see function
maybe_merge_nsegments).
However, VG_(am_mmap_client_heap) has a bug:
* it first mmaps a normal segment (not marked as heap) using
VG_(am_mmap_anon_float_client)
* it then searches the segment that contains the just mmap-ed address and
marks it as heap.
The problem is that VG_(am_mmap_anon_float_client) has already
possibly merged the new segment with a neighbour segment, without
taking the to be marked isCH into account, as the newly allocated memory
has not yet been marked as Client Heap. So, this results in some memory being
marked as client heap, while it in fact is not client heap. This
memory will then not be scanned by the leak search.
The fix consists in having VG_(am_mmap_anon_float_client) and
VG_(am_mmap_client_heap) calling a new function
am_mmap_anon_float_client, which will mark (or not) the new segment as
client heap *before* trying to merge it with neighbouring segments.
Then the new (heap) segment will only be merged with neighbours that are also
client heap segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15759
Current toolchains on MIPS targets that we care about are reasonably
modern and we do not need this link script exception for MIPS anymore.
This should fix issues with newer toolchain versions and .MIPS.abiflags
section.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15754
Changed a few %s or %pS into %ps in m_addrinfo.c
(based on code reading matching the pattern given in the bug report,
as there was no reproducer).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15753
Some recent changes, starting from r15426, have modified the test and
its expected output. The exp files have been only partially updated for
MIPS. We complete that with this change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15752
r15620 changed the test and the expected output for tc18_semabuse,
r15630 fixed the expected output file for other architectures but not
for mips.
Now we update it for mips as well.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15751
On Solaris, the stack frame looks like:
<stack>
<frame>
<ip>0x........</ip>
<obj>/lib/amd64/libc.so.1</obj>
<fn>kill</fn>
</frame>
<frame>
<ip>0x........</ip>
<obj>.../gdbserver_tests/gone</obj>
<fn>(below main)</fn>
</frame>
</stack>
because Solaris libc does not currently contain DWARF CFI and
stack unwinder gets only return address from _start().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15750
On Solaris and Linux, mmap() is an optimized function without
prologue and epilogue. However, Solaris libc does not currently
bear any DWARF CFI. Therefore stack chain unwinder grabs only
two entries: IP inside mmap() and return address from the previous
frame which points inside _start(), right after where main()
is invoked. By introducing an intermediate function f(), main()
is now visible in the stack trace even on Solaris.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15749
