This commit implements in python a set of GDB commands corresponding to the
Valgrind gdbserver monitor commands.
Basically, the idea is that one GDB command is defined for each valgrind
gdbserver subcommand and will generate and send a monitor command to valgrind.
The python code is auto-loaded by GDB as soon as GDB observes that the valgrind
preload core shared lib is loaded (e.g. vgpreload_core-amd64-linux.so).
This automatic loading is done thanks to the .debug_gdb_scripts section
added in vg_preloaded.c file.
Sadly, the auto-load only happens once valgrind has started to execute the code
of ld that loads this vg_preload file.
I have tried 2 approaches to have the python code auto-loaded when attaching at
startup to valgrind:
* have valgrind gdbserver reporting first to GDB that the executable file is
the tool executable (with a .debug_gdb_scripts section) and then reporting
the real (guest) executable file.
The drawback of this approach is that it triggers a warning/question in GDB
according to the GDB setting 'set exec-file-mismatch'.
* have valgrind gdbserver pretending to be multiprocess enabled, and report
a fake process using the tool executable with a .debug_gdb_scripts section.
The drawback of this is that this always creates a second inferior in GDB,
which will be confusing.
Possibly, we might complete the below message :
==2984378== (action at startup) vgdb me ...
==2984378==
==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem
==2984378== and then give GDB the following command
==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378
==2984378== --pid is optional if only one valgrind process is running
with:
==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins.
==2984378== Alternatively, you might load it before with the GDB command:
==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py
The following GDB setting traces the monitor commands sent by a GDB valgrind
command to the valgrind gdbserver:
set debug valgrind-execute-monitor on
How to use the new GDB valgrind commands?
-----------------------------------------
The usage of the GDB front end commands is compatible with the
monitor command as accepted today by Valgrind.
For example, the memcheck monitor command "xb' has the following usage:
xb <addr> [<len>]
With some piece of code:
'char some_mem [5];'
xb can be used the following way:
(gdb) print &some_mem
(gdb) $2 = (char (*)[5]) 0x1ffefffe8b
(gdb) monitor xb 0x1ffefffe8b 5
ff ff ff ff ff
0x4A43040: 0x00 0x00 0x00 0x00 0x00
(gdb)
The same action can be done with the new GDB 'memcheck xb' command:
(gdb) memcheck xb 0x1ffefffe8b 5
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
At this point, you might ask yourself: "what is the interest ?".
Using GDB valgrind commands provides several advantages compared to
the valgrind gdbserver monitor commands.
Evaluation of arguments by GDB:
-------------------------------
For relevant arguments, the GDB command will evaluate its arguments using
the usual GDB evaluation logic, for example, instead of printing/copying
the address and size of 'some_mem', the following will work:
(gdb) memcheck xb &some_mem sizeof(some_mem)
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
or:
(gdb) p some_mem
$4 = "\000\000\000\000"
(gdb) memcheck xb &$4
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
This is both easier to use interactively and easier to use in GDB scripts,
as you can directly use variable names in the GDB valgrind commands.
Command completion by GDB:
--------------------------
The usual command completion in GDB will work for the GDB valgrind commands.
For example, typing TAB after the letter 'l' in:
(gdb) valgrind v.info l
will show the 2 "valgrind v.info" subcommands:
last_error location
(gdb) valgrind v.info l
Note that as usual, GDB will recognise a command as soon as it is unambiguous.
Usual help and apropos support by GDB:
--------------------------------------
The Valgrind gdbserver provides an online help using:
(gdb) monitor help
However, this gives the help for all monitor commands, and is not searchable.
GDB provides a better help and documentation search.
For example, the following commands can be used to get various help
or search the GDB Valgrind command online documentation:
help valgrind
help memcheck
help helgrind
help callgrind
help massif
to get help about the general valgrind commands or the tool specific commands.
Examples of searching the online documentation:
apropos valgrind.*location
apropos -v validity
apropos -v leak
User can define aliases for the valgrind commands:
--------------------------------------------------
The following aliases are predefined:
v and vg for valgrind
mc for memcheck
hg for helgrind
cg for callgrind
ms for massif
So, the following will be equivalent:
(gdb) valgrind v.info location &some_mem
(gdb) v v.i lo &some_mem
(gdb) alias Vl = valgrind v.info location
(gdb) Vl &some_mem
Thanks to Hassan El Karouni for the help in factorising the python
code common to all valgrind python commands using a decorator.
In the memcheck monitor 'leak_search', add a "new" keyword corresponding
to the delta leak search mode LCD_New.
Add a new client request VALGRIND_DO_NEW_LEAK_CHECK.
When doing a delta leak search, new loss records are marked with "new"
(whatever the delta leak search mode).
Note that trailing white spaces were removed in mc_main.c.
A much small diff can be looked at by using the -w diff option.
The URL to the original C++ front-end for GCC internals document
disappeared. Replace it with an URL that still has a description of
the original magic cookie added by operator new [] by that frontend.
This makes the rule for xmllint easier since it doesn't need to
override the DTD to validate against. It also helps with other tools
tryinf to process the docbookx xml files.
- The option --xtree-leak=yes (to output leak result in xtree format)
automatically activates the option --show-leak-kinds=all,
as xtree visualisation tools such as kcachegrind can in any case
select what kind of leak to visualise.
Memcheck tries to accurately track definedness at the bit level, at least
for scalar integer operations. For many operations it is good enough to use
approximations which may overstate the undefinedness of the result of an
operation, provided that fully defined inputs still produce a fully defined
output. For example, the standard analysis for an integer add is
Add#(x#, y#) = Left(UifU(x#, y#))
which (as explained in the USENIX 05 paper
http://valgrind.org/docs/memcheck2005.pdf) means: for an add, worst-case
carry propagation is assumed. So all bits to the left of, and including,
the rightmost undefined bit in either operand, are assumed to be undefined.
As compilers have become increasingly aggressive, some of these
approximations are no longer good enough. For example, LLVM for some years
has used Add operations with partially undefined inputs, when it knows that
the carry propagation will not pollute important parts of the result.
Similarly, both GCC and LLVM will generate integer equality comparisons with
partially undefined inputs in situations where it knows the result of the
comparison will be defined. In both cases, Memcheck's default strategies
give rise to false uninitialised-value errors, and the problem is getting
worse as time goes by.
Memcheck already has expensive (non-default) instrumentation for integer
adds, subtracts, and equality comparisons. Currently these are only used if
you specify --expensive-definedness-checks=yes, and in some rare cases to do
with inlined string operations, as determined by analysing the block to be
instrumented, and by default on MacOS. The performance hit from them can be
quite high, up to 30% lossage.
This patch makes the following changes:
* During instrumentation, there is much finer control over which IROps get
expensive instrumentation. The following groups can now be selected
independently for expensive or cheap instrumentation:
Iop_Add32
Iop_Add64
Iop_Sub32
Iop_Sub64
Iop_CmpEQ32 and Iop_CmpNE32
Iop_CmpEQ64 and Iop_CmpNE64
This makes it possible to only enable, on a given platform, only the minimal
necessary set of expensive cases.
* The default set of expensive cases can be set on a per-platform basis.
This is set up in the first part of MC_(instrument).
* There is a new pre-instrumentation analysis pass. It identifies Iop_Add32
and Iop_Add64 uses for which the expensive handling will give the same
results as the cheap handling. This includes all adds that are used only
to create memory addresses. Given that the expensive handling of adds is,
well, expensive, and that most adds merely create memory addresses, this
more than halves the extra costs of expensive Add handling.
* The pre-existing "bogus literal" detection (0x80808080, etc) pass
has been rolled into the new pre-instrumentation analysis.
* The --expensive-definedness-checks= flag has been changed. Before, it
had two settings, "no" and "yes", with "no" being the default. Now, it
has three settings:
no -- always use the cheapest handling
auto -- use the minimum set of expensive handling needed to get
reasonable results on this platform, and perform
pre-instrumentation analysis so as to minimise the costs thereof
yes -- always use the most expensive handling
The default setting is now "auto". The user-visible effect of the new
default is that there should (hopefully) be a drop in false positive rates
but (unfortunately) also some drop in performance.
As option --xtree-leak=yes is useless without a full leak report,
sets automatically full leak report if xtree leak report is requested.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16206
* New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
to produce the end of execution leak report in a xtree callgrind format
file.
* New option 'xtleak' in the memcheck leak_check monitor command, to
produce the leak report in an xtree file.
* File name template arguments (such as --log-file, --xtree-memory-file, ...)
have a new %n format letter that is replaced by a sequence number.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16205
ignoring accesses on the stack below SP. Serves as a more modern
replacement for --workaround-gcc296-bugs, which is now deprecated.
Fixes#360571.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16073
* rename macro VALGRIND_CREATE_META_MEMPOOL
to VALGRIND_CREATE_MEMPOOL_EXT
* abort execution if a pool is marked as auto_free but is not a meta pool
+ removed test leak-autofreepool-3.vgtest, which now aborts.
* reword/clarify valgrind.h explanations for meta pool
* similarly reword/clarify the manual
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16042
- Auto-frees all chunks assuming that destroying a pool destroys all
objects in the pool
- Uses itself to allocate other memory blocks
Unit tests included.
Fixes BZ#367995
Patch by: Ruurd Beerstra <ruurd.beerstra@infor.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15984
"none" to "all". This helps to reduce the number of possibly
lost blocks, in particular for C++ applications.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15618
Due to the (still to be done) default activation of --leak-check-heuristics=all,
improve the block_list monitor command for easier display of blocks
found reachable via heuristics.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15617
Default value changed following discussion on valdev.
Giving more information for errors with freed blocks can help
when investigating difficult problems (e.g. double free, programs
using 'cleanup list' collecting different types of memory, ...)
Regression tested on various setup (x86, ppc64, s390x, amd64, debian or fedora)
Tests that have only one exp files have been updated to use the output
of the new default value in their .exp file.
Tests having more than one exp file have been changed so as to
specify explicitely the previous clo default value (i.e. adding
--keep-stacktraces=alloc-then-free in the vgtest file).
Possibly, some tests might fail on non tested platforms
(e.g. mips, macos, solaris, tilegx).
Fixes should be straightforward, using one of the above fix techniques.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15597
- A new monitor command 'xb <addr> <len>' shows the validity bits
of <len> bytes at <addr>. Below the validity bits, the byte
values are shown using a layout similar to the GDB command
'x /<len>xb <addr>'. The monitor command 'xb' is easier to use
(in particular on little endian computers) when you need to associate
byte data value with their corresponding validity bits.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15483
pointing at offset 64bit of a block, when the first 8 bytes contains
the block size - 8. This is e.g. used by sqlite3MemMalloc.
Patch by Matthias Schwarzott (with small modif)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14179
r13682 Initial cut at 3.9.0 release notes.
r13683 Remove duplicate NEWS entries for 3.9.0.
r13689 Minor docs/NEWS fixes
r13690 Documentation updates for 3.9.0.
r13691 More documentation updates, re leak-checker changes
r13692 NEWS: Note increased max mem size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13724
Option -v outputs a list of used suppressions. This only gives
the nr of times a suppression was used.
For a leak search, this only gives the nr of loss records that
have been suppressed, but it does not give additional needed details
to understand more precisely what has been suppressed
(i.e. nr of blocks and nr of bytes).
=> Add in the tool interface update_extra_suppression_use and
print_extra_suppression_info functions to allow the tool to record
additioonal use statistics for a suppression. These statistics
can be done depending on the error (and its data) which is suppressed.
Use this in memcheck for the leak suppressions, to maintain and output
the nr of blocks and bytes suppressed by a suppression during
the last leak search.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13651
* initialise leak_check heuristic parameter in the leak_check monitor command
* show the default value (none heuristic) in the monitor help command
(none value chosen as default as this gives a backward compatible
behaviour).
* document the heuristic leak check parameter in memcheck manual
monitor command section
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13631
The option --leak-check-heuristics=heur1,heur2,... can activate
various heuristics to decrease the number of false positive
"possible leaks" for C++ code. The available heuristics are
detecting valid interior pointers to std::stdstring, to new[] allocated
arrays with elements having destructors and to interior pointers pointing
to an inner part of a C++ object using multiple inheritance.
This fixes 280271 Valgrind reports possible memory leaks on still-reachable
std::string
This has been tested on x86/amd64/ppc32/ppc64.
First performance measurements seems to show a neglectible impact on
the leak search.
More feedback welcome both on performance and functional aspects
(false positive 'possibly leaked' rate decrease and/or
false negative 'possibly leaked' rate increase).
Note that the heuristic is not checking that the memory has been
allocated with "new" or "new[]", as it is expected that in some cases,
specific alloc fn are used for c++ objects instead of the standard new/new[].
If needed, we might add an option to check the alloc functions
to be new/new[].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13582
The option --keep-stacktraces controls which stack trace(s) to keep for
malloc'd and/or free'd blocks. This can be used to obtain more information
for 'use after free' errors or to decrease Valgrind memory and/or cpu usage
by recording less information for heap blocks.
This fixes 312913 Dangling pointers error should also report the alloc
stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13223
284540 Memcheck shouldn't count suppressions matching still-reachable allocations
307465 --show-possibly-lost=no should bring down the error count / exit code
Using the options --show-leak-kinds=kind1,kind2,.. and
--errors-for-leak-kinds=kind1,kind2,.., each leak kind (definite, indirect,
possible, reachable) can now be individually reported and/or counted as
an error.
In a leak suppression entry, an optional line 'match-leak-kinds:'
controls which leak kinds are suppressed by this entry.
This is a.o. useful to avoid definite leaks being "catched"
by a suppression entry aimed at suppressing possibly lost blocks.
Default behaviour is the same as 3.8.1
Old args (--show-reachable and --show-possibly-lost) are still accepted.
Addition of a new test (memcheck/tests/lks) testing the new args
and the new suppression line.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13170
about leaked or reachable blocks)
This patch implements two new memcheck gdbserver monitor commands:
block_list <loss_record_nr>
after a leak search, shows the list of blocks of <loss_record_nr>
who_points_at <addr> [<len>]
shows places pointing inside <len> (default 1) bytes at <addr>
(with len 1, only shows "start pointers" pointing exactly to <addr>,
with len > 1, will also show "interior pointers")
Compiled and reg-tested on f12/x86, deb5/amd64, f16/ppc64.
The 'block_list' command is implemented on top of the
lr_array/lc_chunks/lc_extras arrays used during the last leak search.
NB: no impact on the memory for the typical Valgrind usage where a leak
search is only done at the end of the run.
Printing the block_list of a loss record simply consists in scanning the
lc_chunks to find back the chunks corresponding to the loss record for which
block lists is requested.
The 'who_points_at' command is implemented by doing a scan similar to
(but simpler than) the leak search scan.
lc_scan_memory has been enhanced to have a mode to search for a specific
address, rather than to search for all allocated blocks.
VG_(apply_to_GP_regs) has been enhanced to also provide the ThreadId and
register name in the callback function.
The patch touches multiple files (but most changes are easy/trivial or factorise
existing code).
Most significant changes are in memcheck/mc_leakcheck.c :
* changed the LC_Extra struct to remember the clique for indirect leaks
(size of structure not changed).
* made lr_array a static global
* changed lc_scan_memory:
to have a search mode for a specific address (for who_points_at)
(for leak search) to pass a 'current clique' in addition to the clique
leader
so as to have a proper clique hierarchy for indirectly leaked blocks.
* print_results: reset values at the beginning of the print_result of the
next leak search, rather than at the end of print_results of the previous
leak search.
This allows to continue showing the same info for loss records till a new
leak search is done.
* new function print_clique which recursively prints a group of leaked
blocks, starting from the clique leader.
* new function MC_(print_block_list) : calls print_clique for each clique
leader found for the given loss record.
* static void scan_memory_root_set : code extracted from
MC_(detect_memory_leaks) (no relevant change)
* void MC_(who_points_at) : calls scan_memory_root_set, lc_scan_memory
and VG_(apply_to_GP_regs)(search_address_in_GP_reg) to search
pointers to the given address.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12357
to let the user specify a max nr of loss records to output : on huge
applications, interactive display of a lot of records in gdb can
take a lot of time.
* mc_include.h :
- added UInt max_loss_records_output; to LeakCheckParams structure
- avoid passing LeakCheckParams by struct copy.
* modified test gdbserver_tests/mcleak to test the new parameter
* mc_main.c : parse or set max_loss_records_output in leak_check cmd
handling and calls.
* mc-manual.xml : document new leak_check parameter
* mc_leakcheck.c :
- extract printing rules logic in its own function
- in print_results, if there is a limit in LeakCheckParam,
compute from where the printing of loss records has to start
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12329
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
This patch provides three improvements in the way the free list is
handled in memcheck.
First improvement: a new command line option --freelist-big-blocks
(default 1000000) specifies the size of "free list big blocks".
Such big blocks will be put on the free list, but will be re-cycled first
(i.e. in preference to block having a smaller size).
This fixes the bug https://bugs.kde.org/show_bug.cgi?id=250065.
Technically, the freed list is divided in two lists : small
and big blocks. Blocks are first released from the big block list.
Second improvement: the blocks of the freed list are re-cycled before
a new block is malloc-ed, not after a block is freed.
This gives better error messages for dangling pointer errors
when doing many frees without doing malloc between the frees.
(this does not uses more memory).
Third improvement: a block bigger than the free list volume will be
put in the free list (till a malloc is done, so as the needed memory
is not bigger than before) but will be put at the beginning of the
free list, rather than at the end. So, allocating then freeing such a
block does not cause any blocks in the free list to be released.
Results of the improvements above, with the new regression test
memcheck/test/big_blocks_freed_list: with the patch, 7 errors
are detected, 6 are giving the (correct) allocation stack.
Without the patch, only 6 errors are detected, 5 errors without
allocation stack, 1 with a (wrong) allocation stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12202
--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
