This allows to decrease memory usage when using many threads,
if no big stacksize is needed by Valgrind.
If needed (e.g. for demangling big c++ symbols), the V stacksize
can be increased.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15004
for the number of connected processes. This is still lame but better
than asking her to recompile.
Part of fixing BZ #337869.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14838
* This option can be used to mark the begin/end of errors in textual
output mode, to facilitate searching/extracting errors in output files
mixing valgrind errors with program output.
* Use the new option in various existing regtests to test the various
possible usage.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14714
the man page to contain:
></programlisting>
<para>And here are the same errors with
<option>--read-var-info=yes</option>:</para>
<programlisting><![CDATA[
Rather than the nicely formatted 'And here ...' paragraph.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14561
Activating this hint using --sim-hints=no-nptl-pthread-stackcache
means the glibc nptl stack cache will be disabled.
Disabling this stack/tls cache avoids helgrind false positive race conditions
errors when using __thread variables.
Note: disabling the stack cache is done by a kludge, dependent on
internal knowledge of glibc code, and using libpthread debug info.
So, this kludge might be broken with newer glibc version.
This has been tested on various platforms and various
glibc versions 2.11, 2.16 and 2.18
To check if the disabling works, you can do:
valgrind --tool=helgrind --sim-hints=no-nptl-pthread-stackcache -d -v ./helgrind/tests/tls_threads |& grep kludge
If you see the below 2 lines, then hopefully the stack cache has been disabled.
--12624-- deactivate nptl pthread stackcache via kludge: found symbol stack_cache_actsize at addr 0x3AF178
--12624:1:sched pthread stack cache size disabling done via kludge
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14313
* Mention --read-inline-info=yes as an alternative to compile without inlining.
* Mention that stabs debuginfo reader is not working anymore since 3.9.0
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14160
showing inlined function calls.
See 278972 valgrind stacktraces and suppression do not handle inlined function call debuginfo
Reading the inlined dwarf call info is activated using the new clo
--read-inline-info=yes
Default is currently no but an objective is to optimise the performance
and memory in order to possibly set it on by default.
(see below discussion about performances).
Basically, the patch provides the following pieces:
1. Implement a new dwarf3 reader that reads the inlined call info
2. Some performance improvements done for this new parser, and
on some common code between the new parser and the var info parser.
3. Use the parsed inlined info to produce stacktrace showing inlined calls
4. Use the parsed inlined info in the suppression matching and suppression generation
5. and of course, some reg tests
1. new dwarf3 reader:
---------------------
Two options were possible: add the reading of the inlined info
in the current var info dwarf reader, or add a 2nd reader.
The 2nd approach was preferred, for the following reasons:
The var info reader is slow, memory hungry and quite complex.
Having a separate parsing phase for the inlined information
is simpler/faster when just reading the inlined info.
Possibly, a single parser would be faster when using both
--read-var-info=yes and --read-inline-info=yes.
However, var-info being extremely memory/cpu hungry, it is unlikely
to be used often, and having a separate parsing for inlined info
does in any case make not much difference.
(--read-var-info=yes is also now less interesting thanks to commit
r13991, which provides a fast and low memory "reasonable" location
for an address).
The inlined info parser reads the dwarf info to make calls
to priv_storage.h ML_(addInlInfo).
2. performance optimisations
----------------------------
* the abbrev cache has been improved in revision r14035.
* The new parser skips the non interesting DIEs
(the var-info parser has no logic to skip uninteresting DIEs).
* Some other minor perf optimisation here and there.
In total now, on a big executable, 15 seconds CPU are needed to
create the inlined info (on my slow x86 pentium).
With regards to memory, the dinfo arena:
with inlined info: 172281856/121085952 max/curr mmap'd
without : 157892608/106721280 max/curr mmap'd,
So, basically, inlined information costs about 15Mb of memory for
my big executable (compared to first version of the patch, this is
already using less memory, thanks to the strpool deduppoolalloc.
The needed memory can probably be decreased somewhat more.
3. produce better stack traces
------------------------------
VG_(describe_IP) has a new argument InlIPCursor *iipc which allows
to describe inlined function calls by doing repetitive calls
to describe_IP. See pub_tool_debuginfo.h for a description.
4. suppression generation and matching
--------------------------------------
* suppression generation now also uses an InlIPCursor *iipc
to generate a line for each inlined fn call.
* suppression matching: to allow suppression matching to
match one IP to several function calls in a suppression entry,
the 'inputCompleter' object (that allows to lazily generate
function or object names for a stacktrace when matching
an error with a suppression) has been generalised a little bit
more to also lazily generate the input sequence.
VG_(generic_match) has been updated so as to be more generic
with respect to the input completer : when providing an
input completer, VG_(generic_match) does not need anymore
to produce/compute any input itself : this is all delegated
to the input completer.
5. various regtests
-------------------
to test stack traces with inlined calls, and suppressions
of (some of) these errors using inlined fn calls matching.
Work still to do:
-----------------
* improve parsing performance
* improve the memory overhead.
* handling the directory name for files of the inlined function calls is not yet done.
(probably implies to refactor some code)
* see if m_errormgr.c *offsets arrays cannot be managed via xarray
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14036
The current manual and man page tells:
--tool=<toolname> [default: memcheck]
Run the Valgrind tool called toolname, e.g. Memcheck, Cachegrind, etc.
where the toolname examples do not list all the tools, and use uppercase
first letter, which is not understood.
So, use lower case, and give the list of all known tools.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13920
use of some more memory by decreasing the default value
or solve some conflicts with system libraries by increasing the value.
See user manual for details.
Note that the lowest accepted possible value is 0x1000, which is
the current value used by Macos in 32bits.
On linux, 0x10000 (64KB) seems to cause not much conflicts.
Default values are unchanged (i.e. are the same as when there
was no clo option).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13901
to ask GDB server to stop before program execution, at the end
of the program execution and on Valgrind internal errors.
- A new monitor command "v.set hostvisibility" that allows GDB server
to provide access to Valgrind internal host status/memory.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13900
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
A previous commit had decreased to 6 (on android) and increased to 16
(other platforms) the nr of sectors in the translation cache.
This patch adds a command line option to let the user specify
the nr of sectors as e.g. 16 sectors might be a lot and cause
an out of memory for some workloads or might be too small for
huge executable or executables using a lot of shared libs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13652
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
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
(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
* 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
This limit is large enough for all practical purposes. It exists
only to sanity check the value specified with --num-callers.
Be frugal in record_ExeContext_wrk and only allocate on the stack
as many frames as needed.
Testcase included.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12685
* pub_tool_redir.h : define the prefix to be used for "soname synonym"
place holder
* vg_replace_malloc.c : define synonym place holder for malloc related
functions
* m_redir.c : when detecting a soname synonym place holder redir spec, search
in clo_soname_synonyms if there is a synonym pattern.
If yes, replace the soname pattern. If not, ignore the redir spec.
* various files: implement or document the new clo --soname-synonyms
* new test memcheck/tests/static_malloc.vgtest
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12559
A '3 lines how to':
perl tests/vg_regtest --outer-valgrind=../trunk_untouched/install/bin/valgrind --all
(the outer results for a test xxx is in xxx.outer.log)
To run with another tool (e.g. drd), add the argument --outer-tool=drd
Still to do/things to improve:
* Most (inner) tests are successful when running under an outer
memcheck. Need to analyse the reasons of remaining failures.
* The memcheck annotations in m_mallocfree.c can be improved:
- A superblock is marked 'undefined', it should rather be marked
'no access'.
- When a free block is splitted, the remaining free block is
not made 'no access'. Instead, it is made 'undefined'.
=> this decreases the chance to find bugs.
=> this is not very efficient (e.g. the rest of a superblock
is often marked undefined repetitively).
Similarly, the free block created by VG_(arena_memalign)
is marked 'undefined'. 'No access' would be preferrable.
- mkInuseBlock marks the new block as undefined. This is probably
not needed, as VALGRIND_MALLOCLIKE_BLOCK will do it already.
- VG_(arena_malloc) should give the requested size to
VALGRIND_MALLOCLIKE_BLOCK, not the malloc usable size,
as this decreases the chance to find buffer overrun bugs.
But giving the requested size is tricky (see comments in
the code).
* need to do memcheck annotations in m_poolalloc.c
so as to allow leak checking for pool allocated elements.
* vg_regtest.in
- should analyse the results of the outer and should
produce a separate result for the tests for which
the outer detects an error or a memory leak or ...
Changes done:
README_DEVELOPERS: document the new outer/inner features.
manual-core.xml: document the new sim-hint no-inner-prefix
tests/outer_inner.supp: new file, containing the suppressions for inner.
vg_regtest.in: implement new args --outer-valgrind, --outer-tool, --outer-args.
m_mallocfree.c: annotations for memcheck.
m_libcprint.c: handle the new sim-hint no-inner-prefix
m_main.c: do an (early) parse of --sim-hints
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12441
* make a reference to --vex-iropt-precise-memory-exns=yes
to obtain up to date registers values.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12416
* manual-core.xml : fix a typo
* include/pub_tool_inner.h : new file, defining macros for inner annotation
include/Makefile.am : reference this new file.
* syswrap-linux.c : when ENABLE_INNER, register the stacks for the outer.
(otherwise, nothing works properly).
* m_redir.c : avoid inner interpreting the outer vgpreload instructions.
* sema.c : annotate the semaphore with RWLOCK annotations for helgrind
* ticket-lock-linux.c : similar.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12414
a bunch of file-related syscalls to be handled on the might-block
syscall path rather than the fast syscall path. This fixes deadlocks
when running some FUSE-specific filesystem codes. Fixes#278057.
(Mike Shal, marfey@gmail.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11993
