(useful to check the sanity of valgrind on request and/or from GDB,
when an error is reported by the tool).
Also re-order the NEWS entries to put the internals things after
the user level new functions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13262
In a big applications, some recursive algorithms have created
hundreds of thousands of stacktraces, taking a lot of memory.
Option --merge-recursive-frames=<number> tells Valgrind to
detect and merge (collapse) recursive calls when recording stack traces.
The value is changeable using the monitor command
'v.set merge-recursive-frames'.
Also, this provides a new client request: VALGRIND_MONITOR_COMMAND
allowing to execute a gdbsrv monitor command from the client
program.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13246
information about the stack traces recorded by Valgrind.
This can be used to analyse one possible cause of Valgrind high
memory usage for some programs.
At work, a big set of regression tests crashed out of memory under Valgrind.
Two main causes for out of memory were identified:
1. big memory usage for stacktrace (exe contexts) recording by Valgrind
2. big number of partially initialised bytes.
This patch adds a gdbsrv monitor command that output (very) detailed
information about all the recorded exe context.
This has been used to analyse the problem 1. above,
showing the following identified causes for a (too) big nr of execontexts:
A. When the JIT handles an unknown SP update, even when --track-origins=no,
an execontext is (uselessly) created and recorded
to track the (never used) origin of some uninitialised stack memory.
This creates a whole bunch of 'one IP' execontexts.
B. same problem in handling some system calls (at least the brk system
calls always records an origin, even when --track-origins=yes).
C. The Valgrind unwinder cannot properly unwind some stack traces.
It unwinds a few frames, then go bezerk and stops at a "random" IP.
This then causes the same "logical" stacktrace to be truncated
and records thousands of times with this "differentiating" last IP.
For problem cause 2 above ( a lot of partially initialised bytes),
the idea is to similarly add another gdbsrv commands that will output
statistics about which stack traces are causing a lot of uninitialised bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13220
Valgrind 3.8.1 can work with statically linked lib or alternative
malloc libs.
Ensure FAQ properly describe this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13144
(allows to have the list of opened fds and the associated info
on request from GDB or from the shell, using vgdb)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13072
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
on hosts without floating point extension facility.
See companion patch VEX r2501.
Part of fixing bugzilla #306098.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12935
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
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
* 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
