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
Add "memory" to the clobber arguments of VALGRIND_DO_CLIENT_REQUEST_EXPR.
This fixes memcheck/tests/vbit-test/vbit-test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15740
Rewrite parts of VG_(parse_cpuinfo) (previously VG_(get_machine_model))
function to extract information on supported ISAs. These values are then
packed in hwcaps. This will help Valgrind better distinguish different MIPS
CPUs and raise illegal instructions when required.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15739
Power 8 instructions.
The patch for bug 354797 moved the declaration for rc outside of the
architecture #ifdef. This results in an message about rc being unused
on architectures other then s390 and powerpc. This commit eliminates
the issue by:
powerpc: move rc declaration into #ifdef for powerpc.
Remove tab, put in missing break.
s390: remove rc declaration from inside case statement. Put rc declaration
before the switch statement but within the #ifdef for s390 so it will
be declared for use in both case clauses.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15738
Recognize correctly MIPS processors. Previously, for some of the cpu models,
Valgrind would incorrectly assume it is a regular MIPS model, as it would
find word MIPS in /proc/cpuinfo that came from "BogoMIPS" label.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15736
The default implementation provided by __builtin functions
does very weird things.
Uncovered by Philippe's commit r15716.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15734
find_chunk_for has a special case for zero size block.
The special case was missing in the find_chunk_for_OLD.
So, when enabling the leak check debug, the following assert
is raised with ./vg-in-place ./memcheck/tests/leak-0
if you comment the lines (in find_chunk_for_OLD)
if (a_lo == a_hi)
a_hi++; // Special case for szB 0. See find_chunk_for.
and define VG_DEBUG_FIND_CHUNK
Memcheck: mc_leakcheck.c:327 (find_chunk_for): Assertion 'retVal == find_chunk_for_OLD ( ptr, chunks, n_chunks )' failed.
host stacktrace:
==7868== at 0x38031535: show_sched_status_wrk (m_libcassert.c:343)
==7868== by 0x38031641: report_and_quit (m_libcassert.c:415)
==7868== by 0x38031723: vgPlain_assert_fail (m_libcassert.c:481)
==7868== by 0x38004AA6: find_chunk_for (mc_leakcheck.c:327)
==7868== by 0x38005236: lc_is_a_chunk_ptr (mc_leakcheck.c:538)
==7868== by 0x3800556D: lc_push_without_clique_if_a_chunk_ptr (mc_leakcheck.c:893)
==7868== by 0x38035234: apply_to_GPs_of_tid (m_machine.c:199)
==7868== by 0x38035234: vgPlain_apply_to_GP_regs (m_machine.c:425)
==7868== by 0x38006406: vgMemCheck_detect_memory_leaks (mc_leakcheck.c:1913)
==7868== by 0x38015872: mc_handle_client_request (mc_main.c:6628)
==7868== by 0x38047AB8: wrap_tool_handle_client_request (m_tooliface.c:280)
==7868== by 0x3807C5C4: do_client_request (scheduler.c:2101)
==7868== by 0x3807C5C4: vgPlain_scheduler (scheduler.c:1425)
==7868== by 0x38089973: thread_wrapper (syswrap-linux.c:102)
==7868== by 0x38089973: run_a_thread_NORETURN (syswrap-linux.c:155)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15731
On RHEL7 x86 32 bits, Valgrind unwinder cannot properly unwind
the stack just after a thread creation : the unwinder always retrieves
the same pc/sp/bp.
See below for an example.
This has as consequences that some stack traces are bigger than
needed (i.e. they always fill up the ips array). If
--merge-recursive-frames is given, then the unwinder enters in an
infinite loop (as identical frames will be merged, and the ips array
will never be filled in).
Thi patch adds an additional exit condition : after unwinding
a frame, if the previous sp is >= new sp, then unwinding stops.
Patch has been tested on debian 8/x86, RHEL7/x86.
0x0417db67 <+55>: mov 0x18(%esp),%ebx
0x0417db6b <+59>: mov 0x28(%esp),%edi
0x0417db6f <+63>: mov $0x78,%eax
0x0417db74 <+68>: mov %ebx,(%ecx)
0x0417db76 <+70>: int $0x80
=> 0x0417db78 <+72>: pop %edi
0x0417db79 <+73>: pop %esi
0x0417db7a <+74>: pop %ebx
0x0417db7b <+75>: test %eax,%eax
Valgrind stacktrace gives:
==21261== at 0x417DB78: clone (clone.S:110)
==21261== by 0x424702F: ???
==21261== by 0x424702F: ???
==21261== by 0x424702F: ???
==21261== by 0x424702F: ???
==21261== by 0x424702F: ???
==21261== by 0x424702F: ???
==21261== by 0x424702F: ???
...
(till the array of ips is full)
while gdb stacktrace gives:
(gdb) bt
#0 clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110
#1 0x00000000 in ?? ()
(gdb) p $pc
$2 = (void (*)()) 0x417db78 <clone+72>
(gdb)
With the fix, valgrind gives:
==21261== at 0x417DB78: clone (clone.S:110)
==21261== by 0x424702F: ???
which looks more reasonable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15729
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
helgrind accesshistory monitor command
As accesshistory will never show anything unless this option is given.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15723
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
The ISA 2.07 support adds new Iops as well as support for some existing
Iops. None of these Iops have been enabled in the vbit tester. This commit
adds the needed support to the files in memcheck/tests/vbit-test.
These changes add support for additional immediate operands and additional
undefined bit checking functions.
There are additional changes to files VEX/priv/ir_inject.c and VEX/pub/libvex.h
that are in VEX commit 3202
Bugzilla 354797 was created for this issue.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15720
The ELF debug info reader on Solaris now performs a quick pre-scan of section
headers for .rodata sections. If there are multiple .rodata sections
present then symbols from .symtab are scanned which section they point to.
The "true" .rodata section is thus determined.
Fixes BZ#353802.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15719
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
m_replacemalloc/vg_replace_malloc.c:1286:1: warning: returning 'const char *' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
ZONE_GET_NAME(VG_Z_LIBC_SONAME, malloc_get_zone_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1283:14: note: expanded from macro 'ZONE_GET_NAME'
return vg_default_zone.zone_name; \
^~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1287:1: warning: returning 'const char *' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
ZONE_GET_NAME(SO_SYN_MALLOC, malloc_get_zone_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1283:14: note: expanded from macro 'ZONE_GET_NAME'
return vg_default_zone.zone_name; \
^~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1286:1: warning: returning 'const char *' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
ZONE_GET_NAME(VG_Z_LIBC_SONAME, malloc_get_zone_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1283:14: note: expanded from macro 'ZONE_GET_NAME'
return vg_default_zone.zone_name; \
^~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1287:1: warning: returning 'const char *' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
ZONE_GET_NAME(SO_SYN_MALLOC, malloc_get_zone_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
m_replacemalloc/vg_replace_malloc.c:1283:14: note: expanded from macro 'ZONE_GET_NAME'
return vg_default_zone.zone_name; \
^~~~~~~~~~~~~~~~~~~~~~~~~
No regressions on OS X 10.10
Before:
== 596 tests, 219 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 30 post failures ==
After:
== 596 tests, 219 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 30 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15712
Also enhance consistency of formatting for x86 OS X section.
No regressions on OS X 10.10
Before:
== 596 tests, 219 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 30 post failures ==
After:
== 596 tests, 219 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 30 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15706
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
