Massif does not accept to take snapshots of heap before execution has started.
So, if such a snapshot is requested (using vgdb and option --vgdb-error=0),
then such a snapshot must be refused rather than causing an assert.
(problem reported by dark_footix@yahoo.fr)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13015
With some glibc version (e.g. on fedora 16), gdb output contains
a line with T_PSEUDO which should be filtered out.
Patch from Mark Wielaard.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13013
e.g. ccache gcc whatever... This fixes bugzilla #252955.
Patch from Stephen McCamant <smcc@CS.Berkeley.EDU>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12977
an immediate constant as the shift amount. This is needed for
powerpc Iop_ShlD64 etc. What it basically means that we do not
iterate over the bits in the 2nd operand because there are no
V-bits to set. An immediate constant is always completely defined.
Fixes bugzilla #305948.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12969
Testcase, vbit tester update, memcheck support for the new IROps,
NEWS announcement and opcode list update.
Patch by Christian Borntraeger (borntraeger@de.ibm.com).
Vbit tester tweaks by myself.
Fixes bugzilla #274695.
See also companion patch VEX r2496.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12921
After looking more in depth, gdbserver must not be terminated
in PRE(posix_spawn) on MacOS: this is running in the parent and
(on MacOS) is a single syscall similar to a fork+exec.
On linux, posix_spawn is implemented using 2 syscalls
(fork followed by exec).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12882
(patch from Petar Jovanovic).
The mips specific code of vgdb.c was storing the arguments
at wrong places in the ptrace setreg. This caused the blocked syscall(s)
to return with an error rather than to be properly restarted.
With this commit, the gdbsrv tests are not blocking anymore
with Valgrind mips32 running on mips64 GNU/Linux.
vgdb is believed to be functional, even if process is blocked in a syscall.
The following tests are still failing
gdbserver_tests/mcbreak (stdout)
gdbserver_tests/mcbreak (stdoutB)
gdbserver_tests/mcbreak (stderrB)
gdbserver_tests/mcsignopass (stderr)
gdbserver_tests/mcsignopass (stdoutB)
gdbserver_tests/mcsigpass (stderr)
gdbserver_tests/mcsigpass (stdoutB)
gdbserver_tests/nlcontrolc (stdoutB)
gdbserver_tests/nlsigvgdb (stderr)
gdbserver_tests/nlsigvgdb (stderrB)
Of the above, nlsigvgdb failure is still strange.
Others looks like "normal" differences due e.g. to mips specific gdb
behaviour and/or none/tests/faultstatus (re-used in gdbsrv tests)
behaving differently on mips.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12881
default memory limits when building the PDF docs. Fixes#304754.
(Mark Wielaard, mjw@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12863
284540 was not about performance but about the presentation
of results.
Revision 12824 (optimising the suppr matching) should not have
marked 284540 as fixed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12829
Before this patch, matching an error stack trace with many suppression
patterns was implying to repeating the translation of the IPs of the
stack trace to the function name or object name for each suppr pattern.
This patch introduces a "lazy input completer" in the generic match
so that an IP is (in the worst case) translated once to its function
name and once to its object name.
It is a "lazy" completer in the sense that only the needed IP to fun or obj
name are done.
On a artificial test case, has given a factor 3 in performance.
On another big (real) application, gave a factor 2 to 3.
(there was less matching to do, but probably more debug info to search).
match-overrun.supp completed to have non matching suppr first to
better exercise the lazy completer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12824
* Option --vex-iropt-precise-memory-exns has been removed.
It is replaced by --vex-iropt-register-updates which accepts
3 values : 'unwindregs-at-mem-access' (replacing
--vex-iropt-precise-memory-exns=no), 'allregs-at-mem-access'
(replacing --vex-iropt-precise-memory-exns=yes)
and a new value 'allregs-at-each-insn'.
'allregs-at-each-insn' allows the Valgrind gdbserver to always
show up to date values to GDB.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12809
* For tools replacing the malloc library (e.g. Memcheck, Helgrind, ...),
the option --redzone-size=<number> allows to control the padding
blocks (redzones) added before and after each client allocated block.
Smaller redzones decrease the memory needed by Valgrind. Bigger
redzones increase the chance to detect blocks overrun or underrun.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12807
(NB: I am wondering if these entries should be put in NEWS at all.
Is NEWS targetted at end users only ?
Or at "tool developper users also' ?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12796
Valgrind was crashing systematically on Android 4.1.
This crash is caused by AT_IGNORE-ing AT_BASE.
This AT_IGNORE was needed to have breakpoints in shared libs
be handled properly (not very clear what is the problem
in the interaction between Valgrind GDBSERVER, AT_BASE and GDB).
Waiting to better understand all this, as a temporary bypass,
this patch ensures we do not ignore the AT_BASE on android.
The possible consequence is that breakpoints might be inserted
by the Valgrind gdbserver at wrong addresses in shared lib.
(any feedback on that is welcome).
Valgrind was build and then "proved" to work on Android emulator 4.0
and emulator 4.1, by using memcheck on one executable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12758
Scanning 1GB of random values made of 200_000 malloc-ed block is
(on amd64) changing from (about) 17 seconds to (about) 10 seconds.
On x86, it goes from 153 seconds to 129 seconds.
(this huge difference between x86 and amd64 leak search time
for this random test is because a random value has about one chance
on 4 to be in the addressable memory on x86 and so the dichotomic
search in the list of malloc-ed blocks is called for a lot more
values than on amd64).
Basically, there are 3 optimisations:
1. call MC_(is_within_valid_secondary) only at the beginning of a
secondary map (and not for each Word).
2. call SETJMP only at the beginning of a page (and not for each Word)
3. Validate an aligned word using get_vabits8 rather than get_vabits2.
Each of the above optimisation more or less improves by 2 seconds.
(to go from 17 seconds to 10 seconds).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12756
