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
Explanation by Matthias Schwarzott:
The linker will request an executable stack as soon as at least one
object file, that is linked in, wants an executable stack.
And the absence of the
.section .note.GNU-stack."",@progbits
is enough to tell the linker that an executable stack is needed.
So even an empty asm-file must at least contain this statement to not
force executable stacks on the whole executable.
* Define a helper macro MARK_STACK_NO_EXEC that disables the
executable stack.
* Instantiate this macro unconditionally at the end of each asm file.
Patch by Matthias Schwarzott <zzam@gentoo.org>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15692
to memcheck/tests/solaris/ioctl.
While at it, remove a fixed size buffer as reported by Florian Krohm.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15690
Ivo Raisr had reported that thread startup was slow on Solaris.
This patch reduces the thread startup time on Solaris.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15687
in the auxiliary vector.
This is possible as Solaris 12 kernel now creates auxv even
for statically linked binaries.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15682
Comparing the command byte with VKI_I2C_SMBUS_QUICK is like comparing
apples to carrots, it makes no sense. The command byte is unused for
quick transactions anyway so checking its value is pointless.
Patch by Jean Delvare <jdelvare@suse.de>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15656
The first byte of the data array holds the length, so the actual data
length is the value of that byte plus one.
Patch by Jean Delvare <jdelvare@suse.de>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15655
The support for the Valgrind Iops is dependent on the Power processor
support for various instructions. The instructions supported by a
given Power processor is based on the version of the ISA. The patch
add a check to the vbit-test to ensure it does not try to test an Iop
that generates an instruction on the host that is not supported.
This patch fixes bugzilla 352765.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15653
