(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
(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
patch from Mark Wielaard.
(with small modifications).
Also clarified some comments related to the resume reply.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13052
This implies to change the interface between the
arch independent gdbserver files and the arch dependent files
as AVX implies a choice of xml files at run time.
In valgrind-low-amd64.c, the xml files and the nr of registers
are different depending on AVX support or not.
Other platforms still have a fully static nr of registers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12581
AVX support implies to have target xml files which are selected
according to the machine hwcaps.
This change improves the structure of the gdbserver software layering
to prepare for this.
Basically, the protocol files (e.g. server.c) are now calling directly
the valgrind target operations which are now defined in target.h/target.c
(before, there was a level of indirection inheritated from the GDB
structure which was useless for valgrind gdbserver).
+ clarified some comments
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12579
When investigating Valgrind out of memory situation,
it is useful to be able to output the list of segments of the
aspacemgr at any moment.
The GDB monitor command "v.info memory" has now an optional
argument allowing to output this list of segments
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12544
non reset of "C-ontinued" signal
* To allow vki signame to be used in debuglog:
- pub_core_signals.h : added prototype for Char *VG_(signame)
- m_signals.c : changed static const Char *signame(Int sigNo)
to const Char *VG_(signame)(Int sigNo)
* valgrind-low.c : when the signal to report to gdb has
been reported, clear it so that it is not reported anymore
afterwards.
* m_gdbserver.c: when checking in pass_signals if signal
can be passed without gdb interaction, do a conversion
from vki nr to gdb nr when indexing
(as pass_signals[] is indexed by gdb_nr).
* various gdbserver files:
- used vki_ prefix for some args and variables to clarify
- better debuglog tracing
* modified nlpasssigalrm.vgtest to test SIGCHLD signal
handling followed by a break (to see SIGTRAP is properly
given to gdb).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12470
Buffers should not be re-allocated in such a case.
(memory leak detected by running memcheck on memcheck)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12410
Using n_errs_shown allows the user to stop on an error
identified in a previous run by counting errors shown.
* shows also n_errs_shown in monitor command v.info n_errs_found
* slightly clarified the manual, updated to new output of v.info n_errs_found
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12388
* fix various typos in doc
* following commit in gdb
http://sourceware.org/ml/gdb-patches/2011-07/msg00742.html
means unlimited length for valgrind watchpoints is understood by the
(future) gdb 7.4 => doc updated
* factorize gdb version detection and reporting in
gdbserver_tests/make_local_links
* replace zignal by signal in a string used in umsg.
* updated gdbserver_tests/README_DEVELOPPERS (ref to --port vgdb option)
No functional change, tested on f12/x86, debian5/amd64, s390/RHEL4
Fixes#278892. (Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12223
Monitor command useful for debugging/investigation of Valgrind unwinder and/or
gdbserver/gdb stack trace.
The Valgrind unwinder has some limitations compared to the GDB unwinder.
(see e.g. 278972).
With this monitor command, it is easy to see if the Valgrind unwinder
produces something different than the GDB unwinder.
Fixes#279212. (Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12203
--cmd-time-out
* changed prefixes of Valgrind core monitor commands from vg. to v.
* removed prefixes of Tool monitor commands
* memcheck leak_check 'leakpossible' arg renamed to 'possibleleak'
* memcheck make_memory 'ifaddressabledefined' arg renamed to
'Definedifaddressable'
(with uppercase D to avoid confusion with 'defined' arg).
* vgdb options
- Some doc updates : more logical option order documentation,
specify 'standalone' for options aimed at standalone usage.
- added option --cmd-time-out for standalone vgdb
(comment of Josef Weindendorfer, needed to interface with a callgrind GUI)
* updated tests according to the above.
* updated documentation according to the above.
* some additional minor doc fixes/clarifications
(Philippe Waroquiers, philippe.waroquiers@skynet.be). Bug 214909
comment 111.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11844
fix arm thumb by transforming an address to its thumb form when needed
* added a function thumb_pc transforming a pc to its thumb form if needed
(using an heuristic to guess if this is a thumb address)
* when program counter is modified by gdb, use thumb_pc
* use thumb_pc in monitor command vg.translate
(I was able to check that this improves inferior call on a small
thumb compiled executable + mcinfcallRU test) but I could not compile
all tests with thumb).
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11768
