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
(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
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
During investigations of 303963, Josef found that flags are not always
up to date and that --vex-guest-max-insns=1 ensures flags values
are (more?) correct.
=> enhance the paragraph in the gdbserver limitations to reference
this option and give an idea of the performance impact of the other
options helping to increase the precision of registers and flags.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12778
Allow Valgrind to run on android emulator.
+ added README.android_emulator giving some details about versions used.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12710
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
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
* 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
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
Similar to r12444 (see Log below), but this is doing it for x86 and amd64.
The xmm registers are using uint32 or uint64 for their float
union components. For the i387 80 bits float registers, as there is
no uint80, a struct uint16 + uint64 is defined.
Log:
Change the type of the shadow regs for floating point registers
to be uint64. Previously the value in such a shadow reg would
be interpreted by gdb as a floating point value which would
produce non-sensible output for e.g p/x $f1s1.
This patch covers the power and arm architectures.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12445
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
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
* In core advanced manual, replace 3.7.0 by current release.
* cleanup in m_gdbserver/README_DEVELOPPERS
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12320
- mention s390x/linux in README
- formatting tweak in README.s390 so things don't look ugly in html
- add README.s390 and README.android to distribution documents
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12277
* 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
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
--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
