This patch implements the flag --delta-stacktrace=yes/no.
Yes indicates to calculate the full history stack traces by
changing just the last frame if no call/return instruction was
executed.
This can speed up helgrind by up to 25%.
This flags is currently set to yes only on linux x86 and amd64, as some
platform dependent validation of the used heuristics is needed before
setting the default to yes on a platform. See function check_cached_rcec_ok
in libhb_core.c for more details about how to validate/check the behaviour
on a new platform.
Under specific circumstances, setting 2048 as a size of symbol of unknown
size causes that symbol crosses unmapped region. This further causes an
assertion in Valgrind.
Compute possible size by computing maximal size the symbol can have within
its section.
Patch by Tamara Vlahovic.
Detect presence of MSA capabilities.
Contributed by:
Tamara Vlahovic, Aleksandar Rikalo and Aleksandra Karadzic.
Minor code-style rewrites by myself.
Related BZ issue - #382563.
We can have stacktraces such as:
==41840== by 0x10000927: a1 (deep.c:27)
==41840== by 0x1000096F: main (deep.c:35)
==41840== by 0x4126BEB: generic_start_main.isra.0 (in /usr/lib64/libc-2.17.so)
==41840== by 0x4126E13: __libc_start_main (in /usr/lib64/libc-2.17.so)
So, add generic_start_main.isra.0 as a below main function.
This fixes the test massif/tests/deep-D
gdbserver_tests/hgtls is failing on a number of platforms
as it looks like static tls handling is now needed.
So, omplement static tls for a few more platforms.
The formulas that are platform dependent are somewhat wild guesses
obtained with trial and errors.
Note that arm/arm64/ppc32 are not (yet) done
The code handling array bounds is not ready to accept a reference
to something else (not very clear what this reference could be) :
the code only expects directly the value of a bound.
So, it was using the reference (i.e. an offset somewehere in the debug
info) as the value of the bound.
This then gave huge bounds for some arrays, causing an overlap
in the stack variable handling code in exp-sgcheck.
Such references seems to be used sometimes for arrays with variable
size stack allocated.
Fix (or rather bypass) the problem by not considering that we have
a usable array bound when a reference is given.
Implements a new version of VEX register allocator which
keeps the main state per virtual registers, as opposed
to real registers in v2. This results in a simpler and
cleaner design and much simpler implementation.
It has been observed that the new allocator executes 20-30%
faster than the previous one but could produce slightly worse
spilling decisions. Overall performance improvement when running
the Valgrind performance regression test suite has been observed
in terms of a few percent.
The new register allocator (v3) is now the default one.
The old register allocator (v2) is still kept around and can be
activated with command line option '--vex-regalloc-version=2'.
Fixes BZ#381553.
It has been observed that gdb on Solaris sends this signal to
child processes. Unfortunately array "pass_signals" was too small
to accomodate this signal and subsequently VG_(clo_vex_control).iropt_verbosity
was overwritten.
This has been fixed now.
When investigating bug 383275, the host stacktrace was containing
only one IP. This is because the tid corresponding to the lwpid
is dead, and so no valid thread state was returned.
This then gave a rubbish stacktop of 0, which means unwinding
stops at first frame.
So, try harder to find a valid thread state when reporting the
host stacktrace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16470
When a massif xtree snapshot is taken when no allocation was done,
the xtree contains no exe context.
The data structure ips_order_xecu is then szied to 0 using VG_(hintSizeXA).
m_xarray.c then allocates an empty array, while later on, a zero size
is expected to correspond to no allocated array.
Fix the problem in m_xarray.c, by not doing any allocation if the
size hint is 0.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16469
* produce (more) user messages when valgrind cannot read a pdb file.
* recover properly from an invalid/unsupported pdb file.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16465
When running Valgrind under Valgrind, the VEX memory allocation
(temporary or permanent) was not checked, as there was no
inner request.
This patch changes VEX to mark the temporary and permanent
allocations with redzone, and memory is marked unaddressable
when the VEX temporary pool is cleared.
The changes are:
* add a file libvex_inner.h which mostly takes over what
was in pub_core_inner.h (which now just includes libvex_inner.h)
* modify main_util.h and main_util.c to mark the temporary
and permanent pool with memcheck pool requests to indicate
when a block is allocated or freed.
* Impact is (should be) none, unless Valgrind is configured
as an inner.
* Outer memcheck/inner regression tests run on gcc20 (amd64).
Nothing (more worrying than the 3.13 self hosting) detected
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16462
glibc added some security hardening adding (optimized) index/strchr
calls in the LD_PRELOAD path:
commit 6d0ba622891bed9d8394eef1935add53003b12e8
Author: Florian Weimer <fweimer@redhat.com>
Date: Mon Jun 19 22:31:04 2017 +0200
ld.so: Reject overly long LD_PRELOAD path elements
arm32 doesn't have an ld.so hardwire for index/strchr like other
architectures and so will always complain during early startup:
==9495== Conditional jump or move depends on uninitialised value(s)
==9495== at 0x401CF84: index (in /usr/lib/ld-2.25.so)
==9495==
==9495== Conditional jump or move depends on uninitialised value(s)
==9495== at 0x401CF88: index (in /usr/lib/ld-2.25.so)
index/strchr is doing a word load from a partially-written
stack-allocated buffer, therefore accessing uninitialized data.
This is normal for an optimized string function. The uninitialized
data does not affect the function result.
This can be suppressed by adding a index hardwire for ld.so on arm32
like on other arches. There even was already some commented out code
to do that. Enable that code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16458
once the nr of bbs done reaches the next vgdb poll, a check for vgdb
activity is done.
This might lead to the activation of gdbserver after fork.
Such poll is however not expected, unless the children is
to be trace.
This spurious poll in the forked child can cause failures
depending on the nr of bbs done before the fork, and the
nr of bbs done between the fork and the exec.
=> disable vgdb poll in the child in the cleanup after fork
in the child, unless the children have to be traced.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16454
According to the epoll_pwait(2) man page:
The sigmask argument may be specified as NULL, in which case
epoll_pwait() is equivalent to epoll_wait().
But doing that under valgrind gives:
==13887== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s)
==13887== at 0x4F2B940: epoll_pwait (epoll_pwait.c:43)
==13887== by 0x400ADE: main (syscalls-2007.c:89)
==13887== Address 0x0 is not stack'd, malloc'd or (recently) free'd
This is because the sys_epoll_pwait wrapper has:
if (ARG4)
PRE_MEM_READ( "epoll_pwait(sigmask)", ARG5, sizeof(vki_sigset_t) );
Which looks like a typo (ARG4 is timeout and ARG5 is sigmask).
This shows up with newer glibc which translates an epoll_wait call into
an epoll_pwait call with NULL sigmask.
Fix typo and add a testcase.
https://bugs.kde.org/show_bug.cgi?id=381289
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16451
further investigations showing large performance losses in some case, and no
obvious way to fix the problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16428
deschedule the thread much sooner (300 evchecks) than previously (1000
evchecks). Once the thread is spinning, there's absolutely no point in
continuing with it, since only a different thread can get it out of the loop,
so we need to drop the current thread ASAP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16412
be printed only once, rather than every time it happens. Also make it
not be printed in silent mode (-q).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16407
of running modern large applications:
* the maximum number of sectors is increased from 24 to 48
* the default number of sectors is increased from 16 to 32 on all targets
except Android
* the default number of sectors is increased from 6 to 12 on Android targets
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16406
Linux kernel incorrectly shows that MIPS Cavium CPUs do not support mips32r1,
mips32r2 and mips64r1. This is due to incorrect defines in
arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h
that affect show_cpuinfo() function.
Until that is changed in Linux kernel, we need a workaround in Valgrind, so
all supported ISAs can be executed correctly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16390
Fixes BZ#374963.
Previously Valgrind failed to start when the executable contained
large text, data or bss segments. The load address was increased
for almost all platforms to 0x58000000 (from 0x38000000),
giving another 512 MB for the executable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16383
Increase the amount of usable memory from 64GB to 128GB on Linux and Solaris.
(Solaris bits from Ivo Raisr.) OSX is so far unchanged.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16381
- VG_MINIMAL_SETJMP and VG_MINIMAL_LONGJMP for VGP_mips64_linux are defined.
- Implementation of VG_MINIMAL_SETJMP and VG_MINIMAL_LONGJMP for mips32 is
improved by rescuing FP registers.
This should unbreak mips64/clang build.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16378
