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
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
* 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
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
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
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
ms_unrecord_page_mem was wrongly taking the (possible) peak snapshot
when unrecording the last block.
But the peak snapshot will be detected when unrecording the first block
of an munmap, not when unrecording the last block.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15745
Line numbers should correctly reflect all instructions belonging to a source line,
regardless of is_stmt value. Previously only instructions covered by
'is_stmt = 1' were attributed to a source line.
Fixes BZ#356044
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15741
This implements the interception of all globally public allocation
functions by default. It works by adding a flag to the spec to say the
interception only applies to global functions. Which is set for the
somalloc spec. The librarypath to match is set to "*" unless the user
overrides it. Then each DiSym keeps track of whether the symbol is local
or global. For a spec which has isGlobal set only isGlobal symbols will
match.
Note that because of padding to keep the addresses in DiSym aligned the
addition of the extra bool isGlobal doesn't actually grow the struct.
The comments explain how the struct could be made more compact on 32bit
systems, but this isn't as easy on 64bit systems. So I didn't try to do
that in this patch.
For ELF symbols keeping track of which are global is trivial. For pdb I
had to guess and made only the "Public" symbols global. I don't know
how/if macho keeps track of global symbols or not. For now I just mark
all of them local (which just means things work as previously on platforms
that use machos, no non-system symbols are matches by default for somalloc
unless the user explicitly tells which library name to match).
Included are two testcases for shared libraries (wrapmalloc) and staticly
linked (wrapmallocstatic) malloc/free overrides that depend on the new
default. One existing testcase (new_override) was adjusted to explicitly
not use the new somalloc default because it depends on a user defined
new implementation that has side-effects and should explicitly not be
intercepted.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15726
Updated the NEWS file for this fix in VEX commit 3202 and valgrind commit
15720.
Bugzilla 354797 was created for this issue.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15721
All memory dereferences during leak search are checked either with
aspacemgr or using the VA-bits.
So, in theory, no memory fault should occur.
However, the leak search is done so as to resist to e.g.
- desynchronisation between the real pages mapped and the aspacemgr state.
- client pages mprotected against reading
- any other reason why dereferencing a client address would fail.
So, the function lc_scan_memory installs a fault catcher that
is called if a memory fault signal is raised during memory scan.
However, memory dereference is also done in the function heuristic_reachedness.
So, this function must also resist to memory fault.
This patch also installs a fault catcher for the function heuristic_reachedness.
More in details, the following changes are done:
* pub_tool_signal.h and m_signals.c :
VG_(set_fault_catcher) now returns the previously set fault catcher.
This is needed so that heuristic_reachedness/lc_scan_memory can save
and restore the previous fault catcher.
* mc_leakcheck.c:
Addition of leak_search_fault_catcher that contains the common
code for the (currently 2) fault catchers used during leak search.
* Modification of heuristic_reachedness and lc_scan_memory:
Add 2 (small) specific fault catcher that are calling the common
leak_search_fault_catcher.
* The way sigprocmask is handled has been changed:
Before this patch, lc_scan_memory was saving/restoring the procsigmask
for each scanned block (and was restoring it when the fault catcher
was longjmp-ing back to lc_scan_memory in case of SEGV or BUS.
This was causing 2 system calls for each block scanned.
Now, lc_scan_memory and heuristic_reachedness are not saving/restoring
the procmask: the work to reset the sigprocmask is only done
in leak_search_fault_catcher. This is more efficient as no syscall
anymore is done during leak search, except for (normally) unfrequent
SIGSEGV/BUS. It is also simpler as signal handling is now done at
a single place.
It is ok to reset the procmask (in fact, just remove the caught signal
from the process sigmask) as during leak search, no other activity than
the leak search is on-going, and so no other SEGV/BUS can be received
while the handler runs.
This gives moderate speed improvements for applications allocating a lot of
blocks (about 10% improvement when leak searching in 1 million small blocks).
Test case (slightly modified) by Matthias Schwarzott.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15716
that the prerequisites for lock elision are met. Then it may use TBEGIN
and other transactional-execution instructions which are not implemented
by Valgrind. Likewise, the upcoming glibc 2.23 will exploit vector
instructions if they are advertised by HWCAP; and those are currently
not implemented by Valgrind either. In general, the increased use of
ifunc may lead to more such cases in the future.
This patch suppresses the advertising of those hardware features via
HWCAP which are either not known to Valgrind or currently unsupported.
Patch by Andreas Arnez (arnez@linux.vnet.ibm.com).
Fixes BZ #353680.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15702
hardwired absolute path names. People can always arrange $PATH
such that these tools are found.
Fixes BZ #294065. Patch by Austin English <austinenglish@gmail.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15652
s390: Add testcase for fixbr.
Patch by Andreas Arnez <arnez@linux.vnet.ibm.com>.
Part of fixing BZ #350290.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15629
Just add a configure check to see if the assembler understands
fxsave64/fxrstor64 and fall back to the old-school rex64 prefix
otherwise.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15625
"none" to "all". This helps to reduce the number of possibly
lost blocks, in particular for C++ applications.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15618
Due to the (still to be done) default activation of --leak-check-heuristics=all,
improve the block_list monitor command for easier display of blocks
found reachable via heuristics.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15617
