Bug #320116. sockaddr_rc might contain some padding which might not be
initialized. Explicitly check the sockaddr_rc fields are set. That also
produces better diagnostics about which field is unitialized.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13404
Enable wrappers for syscalls prlimit64, process_vm_readv, process_vm_writev,
needed by the following tests:
- none/tests/rlimit64_nofile and
- none/tests/process_vm_readv_writev.
The change also adds definitions for several system calls for MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13400
This change removes option to define shared-memory-alignment for MIPS,
instead default value (0x40000) from MIPS Linux kernel will be used.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13389
MIPS uses different values for socket types.
This is protected by ARCH_HAS_SOCKET_TYPES in Linux kernel and we introduce
it here too. This is important for log-socket feature, and it resolves the
issue reported in https://bugs.kde.org/show_bug.cgi?id=313267#c21.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13359
Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292
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
This generalises the "perm_malloc" function which was in ms_main.c
The new VG_(perm_malloc) is used in ms_main.c
and for execontext : when there are a lot of execontext, this
can save significant memory.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13238
Two fixes could be done:
Either we fix the comments
or we increase N_FRAMES to be rather VG_DEEPEST_BACKTRACE.
We fix the comment for the following reason:
This is (at least for the moment) not performance critical.
as this is only called when an error is reported.
However, searching for local vars is extremely costly.
It is unlikely that an error is reported for a stack variable
which is more than 8 frames deeper than theframe in which
it is detected.
So, fix the comment, waiting for a complaint that a deeper
variable is not properly described.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13235
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
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
all take const HChar * arguments.
__FILE__ and __func__ expand into string literals (or character
arrays initialised by them), as do strings created by the preprocessor
e.g. #stuff.
This change reduces the number of warnings from 17000+ to ~5500
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13039
It's reorg only. No new cache autodetection stuff has been added.
coregrind
pub_tool_cpuid.h is removed as it is no longer exposed to tools.
Its contents has moved to pub_core_cpuid.h.
New file: coregrind/m_cache.c to contain the autodetect code for
cache configurations and define other cache characteristics that
cannot be autodetected (i.e. icaches_maintain_coherence). Most of
cg-arch/x86-amd64.c was moved here. The cache detection code for
x86-64 needs to be fixed to properly initialise VexCacheInfo. It
currently has cachegrind bias.
m_cache.c exports a single function (to coregrind):
VG_(machine_get_cache_info)(VexArchInfo *vai)
This function is called from VG_(machine_get_hwcaps) after hwcaps have
been detected.
cachegrind
Remove cachegrind/cg-{ppc32,ppc43,arm,mips32,s390x,x86-amd64}.c
With the exception of x86/mamd64 those were only establishing a
default cache configuration and that is so small a code snippet that
a separate file is no longer warranted. So, the code was moved to
cg-arch.c. Code was added to extract the relevant info from
x86-amd64.
New function maybe_tweak_LLc which captures the code to massage the
LLc cache configuration into something the simulator can handle. This
was originally in cg-x86-amd64.c but should be used to all architectures.
Changed warning message about missing cache auto-detect feature
to be more useful. Adapted filter-stderr scripts accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13028
From: Ian Campbell <Ian.Campbell@citrix.com>
Under Xen the toolstack is responsible for managing the domains in
the system, e.g. creating, destroying, and otherwise manipulating
them.
To do this it uses a number of ioctls on the /proc/xen/privcmd
device. Most of these (the MMAPBATCH ones) simply set things up such
that a subsequenct mmap call will map the desired guest memory. Since
valgrind has no way of knowing what the memory contains we assume
that it is all initialised (to do otherwise would require valgrind to
be observing the complete state of the system and not just the given
process).
The most interesting ioctl is XEN_IOCTL_PRIVCMD_HYPERCALL which
allows the toolstack to make arbitrary hypercalls. Although the
mechanism here is specific to the OS of the guest running the
toolstack the hypercalls themselves are defined solely by the
hypervisor. Therefore I have split support for this ioctl into a part
in syswrap-linux.c which handles the ioctl itself and passes things
onto a new syswrap-xen.c which handles the specifics of the
hypercalls themselves. Porting this to another OS should just be a
matter of wiring up syswrap-$OS.c to decode the ioctl and call into
syswrap-xen.c. In the future we may want to split this into
syswrap-$ARCH-xen.c but for now this is x86 only.
The hypercall coverage here is pretty small but is enough to get
reasonable(-ish) results out of the xl toolstack when listing,
creating and destroying domains.
One issue is that the hypercalls which are exlusively used by the
toolstacks (as opposed to those used by guest operating systems) are
not considered a stable ABI, since the hypervisor and the lowlevel
tools are considered a matched pair. This covers the sysctl and
domctl hypercalls which are a fairly large chunk of the support
here. I'm not sure how to solve this without invoking a massive
amount of duplication. Right now this targets the Xen unstable
interface (which will shortly be released as Xen 4.2), perhaps I can
get away with deferring this problem until the first change .
On the plus side the vast majority of hypercalls are not of interest
to the toolstack (they are used by guests) so we can get away without
implementing them.
Note: a hypercall only reads as many words from the ioctl arg
struct as there are actual arguments to that hypercall and the
toolstack only initialises the arguments which are used. However
there is no space in the DEFN_PRE_TEMPLATE prototype to allow this to
be communicated from syswrap-xen.c back to syswrap-linux.c. Since a
hypercall can have at most 5 arguments I have hackily stolen ARG8 for
this purpose.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12963
This is a slightly modified version of a patch provided by Petar Jovanovic
<petar.jovanovic@rt-rk.com>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12960
The tester is located in memcheck/tests/vbit-test.
It needs the following support on the valgrind / VEX side:
(1) a new client request VG_USERREQ__VEX_INIT_FOR_IRI
(2) a new "special instruction" on all architectures inserted via
VALGRIND_VEX_INJECT_IR
(3) VEX changes to detect the special insn and insert IR (ir_inject.c)
The README file in vbit-test has some more information.
See also VEX r2490. Fixes bugzilla #300102.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12906
fixes two problems: first, r11 (aka fp) can't be used in assembly
for whatever reason. Secondly, the "bic sp,sp,#7" is not allowed
in Thumb mode, so work around that too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12832
Before this patch, matching an error stack trace with many suppression
patterns was implying to repeating the translation of the IPs of the
stack trace to the function name or object name for each suppr pattern.
This patch introduces a "lazy input completer" in the generic match
so that an IP is (in the worst case) translated once to its function
name and once to its object name.
It is a "lazy" completer in the sense that only the needed IP to fun or obj
name are done.
On a artificial test case, has given a factor 3 in performance.
On another big (real) application, gave a factor 2 to 3.
(there was less matching to do, but probably more debug info to search).
match-overrun.supp completed to have non matching suppr first to
better exercise the lazy completer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12824
