* 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
to put a "marker" msg in process log output
* v.info n_errs_found accepts optional msg, added in the output of
the monitor command.
* use VG_(printf) rather than VG_(gdb_printf) when output of command
should be redirected according to v.set gdb_output|log_output|mixed_output
* also avoid calling gdb_printf in output sink processing
to output zero bytes, as gdb_printf expects to have a null terminated
string, which is not ensured when 0 bytes have to be output.
* some minor reformatting (replace char* xxx by char *xxx).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13532
* modify mcwatchpoints to print a 50000 char array
* add an assert to check the max allowed size
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13476
On MIPS64 address of 'undefined' can be 64-bit width.
When we are trying to access that address we need to use 0x%lx
instead of 0x%x.
Fixes gdbserver_tests/mcvabits for MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13457
On Ubuntu systems, ptrace_scoping could forbid a process to ptrace another.
This ptrace scoping was already handled for vgdb by using SET_PTRACER
(the valgrind process must be ptraced by vgdb when it is blocked
in a syscall).
set_ptracer is however also needed when the old mechanism --db-attach=yes
is used.
The following changes are done:
* make the set_ptracer logic callable outside gdbserver
* make set_ptracer less restrictive (i.e. allow all
processes of the user to ptrace). This removes a limitation for vgdb.
* call the set_ptracer in the child launched for --db-attach=yes
* cleaned up the ptrace scope restriction message and doc as vgdb
is now working properly by default, even with ptrace_scope enabled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13384
Assertion
valgrind: m_transtab.c:674 (find_TTEntry_from_hcode):
Assertion '(UChar*)sec->tt[tteNo].tcptr <= (UChar*)hcode' failed.
failure (encountered on some platforms while running gdbsrv tests).
The problem is related to invalidated entries and the host_extents
mapping between hostcode and the translation table entry.
The problem: when an entry is invalidated, the translation table
entry is changed to status Deleted. However, the host extent array
element is not cleaned up.
If a search for a host code address (find_TTEntry_from_hcode)
finds this entry, the translation table entry in Deleted status
is considered as a 'not found', which ensures that the invalidated
entry is not used (e.g. for chaining).
This is all ok.
However, it might be that this Deleted entry is re-used
(see function VG_(add_to_transtab), searching for a Empty
or Deleted entry.
If the Deleted entry is re-used, then a search for the
dead host code can give a result pointing to the re-used
entry. That is clearly wrong.
Note that it is unclear if this bug can only be triggered
while using gdbsrv or if this bug can be triggered with
just the "normal" invalidation logic of translation.
gdbsrv being a heavy "user" of invalidation, it might
be it helps to trigger the code. Alternatively, as gdbsrv
invalidation is special (e.g. invalidation of some entries
is done during translation of other entries), it might be
the bug is specific to gdbsrv.
In any case, to avoid the bug:
searching for an host code address must not only
ignore Deleted entries, but must also ignore an entry
found via a host_extent element which is for a Deleted
entry that was re-used afterwards (pointed to by a
newer host_extent element).
Multiple solutions are possible for fixing the bug:
Sol1: cleanup the host_extents array when an entry is deleted.
The cleanup is however deemed costly:
Each invalidate operation must do a search in the host_extents.
The host_extents array must then be "compacted" to remove
the "dead" host extent element from the array.
The compact operation can be avoided if instead of removing
the element, one marks instead the element as "dead"
e.g. by using one bit of UInt len for that:
UInt len : 31;
Bool dead : 1;
This avoids the compact, but still incurrs the cost of
search and modify the host_extent for each entry invalidated.
Invalidating entries seems to be a critical operation
(e.g. specific ECLASS related data structures have been
done to allow fast deletion).
=> it is deemed that a solution not incurring cost during
invaliation is preferrable.
* Sol 2: detect in find_TTEntry_from_hcode
that the host_extent element is re-used, and handle it similarly
to an host_extents which points at a Deleted entry.
This detection is possible as if an entry is re-used after
having been deleted, this implies that its host code will be
after the end of the host code of the deleted entry
(as host code of a sector is not re-used).
The attached patch implements this solution.
* Sol 3: avoid re-using an entry : the entry would then stay
in Deleted state. This is deemed not ok as it would
imply that invalidation of entries will cause a sector to
become full faster.
The patch:
* adds a new function
Bool HostExtent__is_dead (const HostExtent* hx, const Sector* sec)
telling if the host extent hx from sector sec is a dead entry.
* this function is used in find_TTEntry_from_hcode so that
dead host extents are not resulting in host code to be found.
* adds a regression test which caused the assert failure before
(bug was found/reported/isolated in a small test case by Dejan Jevtic).
* To check the logic of HostExtent__is_dead, m_transtab.c sanity check is
completed to verify that the nr of entries in use in a sector is equal
to the nr of non dead entries in the host extent array.
* adds/improves traces in m_transtab.c (enabled at compile
time using #define DEBUG_TRANSTAB).
Some already existing 'if (0)' conditions are replaced
by if (DEBUG_TRANSTAB)
Regression tested on
f12/x86
debian6/amd64 (also with export EXTRA_REGTEST_OPTS=--sanity-level=4)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13290
(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
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
(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
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
On mips32, 10 is SIGBUS. This was making all tests using
simulate_control_c looping for ever or a long time.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12873
* 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
GDB can create watchpoints watching the same address.
This was causing assertion failures.
To handle this, hash table (with key watched address) is replaced
by an xarray of address/lengh/kind.
Fully identical watches are ignored (either not inserted, and
not causing a problem if already deleted).
gdbserver_tests/mcwatchpoint enhanced to test duplicated watchpoints
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12637
The test will very probably fail on MacOS (as gdb output will contain SIGUSR1
rather than signal SIGRTMIN, but at least it should compile).
(not tested on MacOS; just tested that it still works on linux)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12594
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
* gdbserver_tests/nlpasssigalrm
modify test so as to test also a real time signal
* coregrind/m_gdbserver/signals.c
- implement translation between gdb real time signal numbers
and vki real time signal numbers
- ensure non-convertible signals are giving an error
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12471
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
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
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
* 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
replaces r12124. His analysis of the testcase failure:
I think I understand what is happening: even if the ptrace invoker functionality
is not needed, the timeout to invoke might expire, which then leads
to a message produced by vgdb if ptrace is restricted by the kernel.
I think the best way to fix this is to add the option --max-invoke-ms=0 to vgdb.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12130
and update exp files accordingly. This works well for x86
and all testcases pass on my machine.
New file filter_memcheck to do the work.
There is a bit of a ripple here as filter_memcheck requires
command line arguments to be passed in. So all users of
filter_memcheck (direct or indirect) were updated as well.
filter_stderr was simplified as was filter_libc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12091
Fixes#276987. (Philippe Waroquiers, philippe.waroquiers@skynet.be)
* make_local_links
- disable gdb tests if gdb version < 7
- disable pic tests if gdb version < 7.1
* nlfork_chain test
- reduce chain from 20 to 15 to avoid ENOMEM
on small ARM systems
* main_pic.c
- put break at line 11 rather than main entry, as ARM gdb
does not properly show main args till it has started executing.
* passsigalrm.c
- do not setsa.sa_restorer (obsolete on linux, unknown on darwin)
* mcvabits.vgtest
- make prereq consistent with other tests
* filter_gdb
- upgraded filter to new linenr in clean_after_fork.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11853
--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 error in usability msg
* make a test more deterministic
(Philippe Waroquiers, philippe.waroquiers@skynet.be). Bug 214909
comment 107.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11835
--vgdb-error=N is specified, print a bit of text telling the user the
magic commands to give GDB in order to attach to the process.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11822
Patch that fixes the problem reported by Christian Borntraeger.
The problem was created by keeping the shared memory mapped file opened
without reason till the process does an exec.
In case of a chain of forked processes (without exec), the range of safe_fd
reserved for Valgrind own usage becomes exhausted.
* coregrind/m_gdbserver/remote-utils.c :
do not VG_(safe_fd) shared_mem_fd (as it is now closed directly)
close shared_mem_fd once file is mmap-ed and written.
* gdbserver_tests/nlfork_chain.stderr.exp,nlfork_chain.vgtest,
fork_chain.c,nlfork_chain.stdout.exp:
new files
* gdbserver_tests/Makefile.am:
modified for new nlfork_chain test
(patch from #214909 c 103,
Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11818
fix mcsig(no)pass on arm Ubuntu10, arm thumb internal doc, improve
simulate_control_c
* new file docs/internals/arm_thumb_notes_gdbserver.txt
documentation about the subtilities of the thumb bit handling in gdbsrv.
* made the SIGFPE backtrace filtering less dependent on gdb/os/libc/...
* improved simulate_control_c : runs faster/less dependent on timeout value
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11791
* Disabled several tests on ARM when gdb version < 7.1
gdb 7.0 has problems with next/step/... in ARM thumb code.
* Documented in manual-core.xml that ARM thumb code implies
a gdb version >= 7.1
* m_gdbserver.h/.c : take into account the thumb bit at several places
* use new IRStmt_IMark::delta field to distinguish ARM vs Thumb
instructions as committed in vex r2153
Patch from bug 214909 comment 99 (valgrind part).
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11779
Fix some tests on ppc-debian6,s390x + handled Nick Nethercote, Josef
Weidendorfer comments
* improved testing & related doc
- added option --vex-iropt-precise-memory-exns=yes to mcsig(no)pass.vgtest
+ updated manual-core.xml
- cleanup some comments in *.vgtest
- modified filter_gdb and filter_memcheck_monitor to
handle specific ppc/debian6.0 mcsig(no)pass output
handle specific s390x 'missing debug info'
- added more information in README_DEVELOPPERS on how to
investigate failing gdbserver tests.
* handled Nick Nethercote comment:
Replaced kludgy ms.snapshot detailed
by ms.detailed_snaphot
Updated documentation and test.
* handled Josef Weindendorfer comments:
- do not report an error if ptrace_scope file can't be read.
Instead, a debug trace is done if -d (debug) option given
- added an option -l to give the list of active Valgrind
gdbserver. Useful a.o. to support callgrind_control.
Updated documentation
- added ref. to vgdb help in the vgdb --help message
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11770
