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
envB: var=value
in the .vgtest file. This is similar to "env:" except the environment
variable is set prior to invoking progB.
Adapt gdbserver_tests/nlgone_exit.vgtest to fix a problem reported
by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15592
GDB is correct that we don't support that at the moment.
See bug #351792 - vgdb doesn't support remote file transfers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15591
At least on x86+gcc4.9, the test fails because step+finish
makes the program stop on the breakme call line (after the call)
instead of reaching line 120.
So; change the gdb commands so as to ensure we reach line 120
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15504
- 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
gdb 7.9 reports new threads at different moment than the previous versions.
Filter these new threads lines so as to not be dependent on this
gdb aspect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15347
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
Some gdb versions don't show the source line:number after switching
threads in #0 0x........ in do_burn (). Filter "at line:number" out
and don't expect it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14427
Some filters might have left some empty lines in the output. Filter them
out explicitly and don't expect any empty lines in any of the .exp files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14381
Some versions of gdb might try to print the entry value of an
argument if they know it with @entry=... Filter that out too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14380
Older GDB (7.2 on i386) don't print out which variable+offset an argument
pointer in a breakpoint function points to. The hgtls test already tests
whether the p pointer/test points to the expected tests array element.
So don't expect gdb to print it also and filter it out with filter_gdb.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14331
HAVE_DLINFO_RTLD_DI_TLS_MODID.
* add the copyright notice in auxprogs/getoff.c
* add more prereq to hgtls.vgtest
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14297
* remove useless commented line in hgtls.vgtest
* avoid some #ifdef in arch specific code, hoping to discover more compile
time errors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14287
To implement QGetTlsAddr, gdbsrv has to know how to get the glibc dtv
address and the module id from the link_map.
These 2 things are dependent on the internals of glibc.
The dependency is mostly isolated in a few lines of arch dependent
code or in an external utility that used a hack + -ldl lib to find
the offset of the modid in the link_map structure.
Tested on x86/amd64/ppc64/s390x. Somewhat tested on ppc32 and arm64.
Untested/a few #ifdef-ed lines not compiled on arm/mips32/mips64
and darwin.
For more background info about thread local storage handling, see
'ELF Handling For Thread-Local Storage' http://www.akkadia.org/drepper/tls.pdf
Changes:
* auxprogs/getoff.c new auxilliary program to get platform specific offsets
(currently only the offset for the module id in struct link_map).
* configure.ac : check for dlinfo(RTLD_DI_TLS_MODID) needed for getoff.c
* new gdbserver_tests/hgtls, testing various types of __thread variables
* various m_gdbserver files:
- implement decoding of the QGetTlsAddr query
- for each platform: platform specific code to get the dtv
- call to external program getoff-<platform> the first time an
__thread variable is printed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14283
observed on a RHEL5 system on s390. Provide a suitable definition.
Tweak gdbserver_tests/filter_stderr to ignore messages related to
interrupted poll system calls.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14197
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
and stack address description.
* A race condition on an allocated block shows the stacktrace, but
does not show the thread # that allocated the block.
This patch adds the output of the thread # that allocated the block.
* The patch also fixes the confusion that might appear between
the core threadid and the helgrind thread nr in Stack address description:
A printed stack addrinfo was containing a thread id, while all other helgrind
messages are using (supposed to use) an 'helgrind thread #' which
is used in the thread announcement.
Basically, the idea is to let a tool set a "tool specific thread nr'
in an addrinfo.
The pretty printing of the addrinfo is then by preference showing this
thread nr (if it was set, i.e. different of 0).
Currently, only helgrind uses this addrinfo tnr.
Note: in xml mode, the output is matching the protocol description.
I.e., GUI should not be impacted by this change, if they properly implement
the xml protocol.
* Also, make the output produced by m_addrinfo consistent:
The message 'block was alloc'd at' is changed to be like all other
output : one character indent, and starting with an uppercase
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14175
of memcheck and helgrind in a common module:
pub_tool_addrinfo.h pub_core_addrinfo.h m_addrinfo.c
At the same time, the factorised code is made usable by other
tools also (and is used by the gdbserver command 'v.info location'
which replaces the helgrind 'describe addr' introduced 1 week ago
and which is now callable by all tools).
The new address description code can describe more addresses
(e.g. for memcheck, if the block is not on the free list anymore,
but is in an arena free list, this will also be described).
Similarly, helgrind address description can now describe more addresses
when --read-var-info=no is given (e.g. global symbols are
described, or addresses on the stack are described as
being on the stack, freed blocks in the arena free list are
described, ...).
See e.g. the change in helgrind/tests/annotate_rwlock.stderr.exp
or locked_vs_unlocked2.stderr.exp
The patch touches many files, but is basically a lot of improvements
in helgrind output files.
The code changes are mostly refactorisation of existing code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13965
+38 ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.
This should make nlgone_exit work on s390 suse and x86_64 suse
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13913
a guardcmd before sending the signal.
This allows to be sure that the signal are emitted when vgdb
is attached.
We still have one 'sleep' in the test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13912
What needs to be ensured is:
vgdb is attached (i.e. is ptracing valgrind)
2 sigusr1 signals are sent while vgdb is ptracing
vgdb will queue these signals
when continuing, the queued signals are delivered.
With 3.9.0, the above causes an internal error in valgrind:
valgrind: m_syswrap/syswrap-main.c:1436 (vgPlain_client_syscall): Assertion 'sci->status.what == SsIdle' failed.
It would be better to have explicit synchronisation in the test
rather than counting on 'sleep xxx' to have things done in the
order that tests the signal queueing.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13910
stacktrace for the last program instruction encountered with
--vgdb-stop-at=exit
These are not needed anymore, as these lines are now removed
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13907
of a program => let's remove these (uninteresting) lines
rather than trying to 'sed' them to make them look the same
on different OS/platform/....
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13906
* remove empty lines from nlgone_*.stdinB.gdb, as these empty
lines are (surprisingly) repeating the previous gdb command.
Empty lines should be be put in the *gdb files.
* And add yet another sed expression in filter_gdb to cope with
the different place where a thread exits.
(this filter technique is now *really* arriving in a dead end
e.g. the link between the comment and the sed expression is very
poor).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13905
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
Most of the time, Valgrind masks async signals, and polls for such
signals at regular interval.
There is a very narrow range of code (around client syscall logic)
where such signals are unmasked (as they must be able to interrupt
syscalls).
This is the only range of code where Valgrind is expecting to
receive such a signal.
When gdbserver is ptraced invoked, Valgrind is artificially made
to jump out of this code portion. Signals are not masked.
When ptraceing valgrind, vgdb will get these signals but cannot
transmit them immediately, otherwise they arrive in range
of code where they are not expected (causing internal error
in syscall logic) and/or causing gdbserver syscalls to be
interrupted.
3 solutions to solve that were looked at:
1. have the gdbserver code masking signals "as quickly as possible".
Easy to implement, but this leaves still a small window
of code where signals are not masked and would cause a problem.
2. have vgdb setting the SIGMASK of valgrind before invoking
gdbserver.
This would be easy to implement, but changing the SIGMASK
of the ptrace-d process is only available on very recent kernels.
3. have vgdb queuing signals, and only transmitting them once
gdbserver invocation is finished.
This 3rd solution has been implemented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13896
* addition of VG_(needs_print_stats) in pub_tool_tooliface.h
* use the above in memcheck and helgrind
* output valgrind stats and calls print_stats in server.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13760
vgdb.c contained (conditionally compiled) "invoker" code to have ptrace syscalls
used to allow gdb/vgdb to connect to a valgrind process blocked in a syscall.
This "invoker" code is ptrace based.
Not all platforms are using ptrace.
=> refactor vgdb so as allow invoker code to be added more cleanly
for non ptrace based platforms (e.g. Darwin, Solaris).
* add file vgdb.h for:
- definition of the vgdb-invoker interface
- common declarations between vgdb.c and vgdb-invoker implementations
* move ptrace related code from vgdb.c to new file vgdb-invoker-ptrace.c
* new file vgdb-invoker-none.c containing an empty invoker implementation
used on platforms that do not (yet) have a invoker implementation
(e.g. android and darwin).
* modified Makefile.am to use one of the vgdb-invoker-*.c file depending
on the platform.
* small changes related to changing ptraceinvoker to invoker in various files:
gdbserver_tests/make_local_links, gdbserver_tests/nlcontrolc.vgtest,
gdbserver_tests/mcinvokeRU.vgtest, gdbserver_tests/nlsigvgdb.vgtest
gdbserver_tests/mcinvokeWS.vgtest, coregrind/m_gdbserver/README_DEVELOPERS
Patch from Ivo Raisr, slightly modified
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13743
* 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
