Files in the root directory
Several Makefile.am files that have dependencies on FreeBSD autoconf
variables. Included a few new filter files to act as placeholders
to create new freebsd subdirectories.
Updated NEWS with the FreeBSD bugzilla items plus a couple of other
items fixed indirectly.
glibc 2.34 moved all pthread functions into the main libc library.
And it changed the (in memory) path of the main libc library to
libc.so.6 (before it was libc-2.xx.so).
This breaks various standard suppressions for helgrind and drd.
Fix this by doing a configure check for whether we are using glibc
2.34 by checking whether pthread_create is in libc instead of in
libpthread. If we are using glibc then define GLIBC_LIBC_PATH and
GLIBC_LIBPTHREAD_PATH variables that point to the (regexp) path
of the library that contains all libc functions and pthread functions
(which will be the same path for glibc 2.34+).
Rename glibc-2.34567-NPTL-helgrind.supp to glibc-2.X-helgrind.supp.in
and glibc-2.X-drd.supp to glibc-2.X-drd.supp.in and replace the
GLIBC_LIBC_PATH and GLIBC_LIBPTHREAD_PATH at configure time.
The same could be done for the glibc-2.X.supp.in file, but hasn't
yet because it looks like most suppressions in that file are obsolete.
vglibdir is the directory from where valgrind loads its internal tool
executables and vgpreloads. Currently vglibdir is pkglibdir, so those
internal tools are intermingeled with normal executables and libraries
that the user might use directly.
Make vglibdir equal to pkglibexecdir so the internal tools get installed
and loaded from libexec and don't get get stored under lib.
This leaves just the static archives and the mpiwrapper libraries that
the user would link/load themselves under pkglibdir.
This seems more in line with the FHS lib/libexec standard and makes it
slightly easier to combine the tools from a multilib target (say the
memcheck-amd64-linux and memcheck-x86-linux tools) because they would
be installed under the same directory, while the pkglibdir can differ
depending on arch/target (lib/lib64).
https://bugs.kde.org/show_bug.cgi?id=433323
Replace the gsl16test script under auxprogs that you run by hand
with a new make target auxchecks which fetches the source code,
patches, reconfigures and builds all tests. Then run all tests
under valgrind.
It only ever worked on x86 and amd64, and even on those it had a high false
positive rate and was slow. Everything it does, ASan can do faster, better,
and on more architectures. So there's no reason to keep this tool any more.
Ensure this documentation file is included in tarball.
Fixes: 9f3d49a ("Create 3.10.0 section in NEWS, add (first draft of) README_DEVELOPERS_processes")
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
This approach is utilized consistently throughout the file, and would make
alphabetical reordering easier. Adopt it here as well.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Avoid use of two manners of setting automake configuration options,
and consolidate them into AM_INIT_AUTOMAKE macro.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
This commit thoroughly overhauls DHAT, moving it out of the
"experimental" ghetto. It makes moderate changes to DHAT itself,
including dumping profiling data to a JSON format output file. It also
implements a new data viewer (as a web app, in dhat/dh_view.html).
The main benefits over the old DHAT are as follows.
- The separation of data collection and presentation means you can run a
program once under DHAT and then sort the data in various ways. Also,
full data is in the output file, and the viewer chooses what to omit.
- The data can be sorted in more ways than previously. Some of these
sorts involve useful filters such as "short-lived" and "zero reads or
zero writes".
- The tree structure view avoids the need to choose stack trace depth.
This avoids both the problem of not enough depth (when records that
should be distinct are combined, and may not contain enough
information to be actionable) and the problem of too much depth (when
records that should be combined are separated, making them seem less
important than they really are).
- Byte and block measures are shown with a percentage relative to the
global count, which helps gauge relative significance of different
parts of the profile.
- Byte and blocks measures are also shown with an allocation rate
(bytes and blocks per million instructions), which enables comparisons
across multiple profiles, even if those profiles represent different
workloads.
- Both global and per-node measurements are taken at the global heap
peak ("At t-gmax"), which gives Massif-like insight into the point of
peak memory use.
- The final/liftimes stats are a bit more useful than the old deaths
stats. (E.g. the old deaths stats didn't take into account lifetimes
of unfreed blocks.)
- The handling of realloc() has changed. The sequence `p = malloc(100);
realloc(p, 200);` now increases the total block count by 2 and the
total byte count by 300. Previously it increased them by 1 and 200.
The new handling is a more operational view that better reflects the
effect of allocations on performance. It makes a significant
difference in the results, giving paths involving reallocation (e.g.
repeated pushing to a growing vector) more prominence.
Other things of note:
- There is now testing, both regression tests that run within the
standard test suite, and viewer-specific tests that cannot run within
the standard test suite. The latter are run by loading
dh_view.html?test=1 in a web browser.
- The commit puts all tool lists in Makefiles (and similar files) in the
following consistent order: memcheck, cachegrind, callgrind, helgrind,
drd, massif, dhat, lackey, none; exp-sgcheck, exp-bbv.
- A lot of fields in dh_main.c have been given more descriptive names.
Those names now match those used in dh_view.js.
Create a file vgversion_dist.h in the tarball.
This file is not deleted by make clean
Change auxprogs/make_or_upd_vgversion_h to use vgversion_dist.h if it is
available.
Add some missing quotes to auxprogs/make_or_upd_vgversion_h
Patch by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16398
Make sure to include the builddir include directory to find the
generated vgversion.h. Make include/vgversion.h a .PHONY target
so it always gets regenerated even if the file is already there.
Make sure to run svnversion in the srcdir.
Patch by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16397
Patch by Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>.
Partial fix. make && make check now works with builddir != srcdir.
But make regtest doesn't yet.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13949
are not against the grain.
Wrap this script together with 'check_makefile_consistency' into
'post_regtest_checks' and invoke that from the toplevel Makefile. So we can
easily add new checkers in the future.
Add a new make target 'post-regtest-checks' to just run those checks
and nothing else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13570
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
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
in .S files. Also included here is some cleanup, including a reversion
of r10378. Fixes bugzilla #197914.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12555
* configure.in support
* new supp file darwin11.supp
* comment out many intercepts in mc_replace_strmem.c and
vg_replace_malloc.c that are apparently unnecessary for Darwin
* add minimal handling for the following new syscalls and mach traps:
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
* wqthread_hijack on amd64-darwin: deal with
tst->os_state.pthread having an apparently different offset,
which caused an assertion failure
* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
cleanup added in r12041/12042 to handle apparently new dyld
behaviour, which is to map text areas r-- first and only
vm_protect them later to r-x.
The following cleanups remain to be done
* remove apparently pointless, commented out wrapper macro
invokations in mc_replace_strmem.c, eg
//MEMMOVE(VG_Z_DYLD, memmove)
(or determine that they are still necessary, and uncomment)
* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
there
* write proper syscall wrappers for
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
These are currently just no-ops and may be causing Memcheck to
report false undef-value errors
* figure out why it doesn't work properly unless built with gcc-4.2 on
Lion.
gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1). Plain
gcc is the hybrid gcc-front-end clang-back-end thing
(i686-apple-darwin11-llvm-gcc-4.2). Whereas on Snow Leopard, plain
gcc is the normal gcc.
The symptoms of the failure are that wqthread_hijack in
syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
at the end (you need a pretty complex threaded app to trigger this),
which makes me think that either ML_(wqthread_continue_NORETURN) or
call_on_new_stack_0_1 do return, which they are not expected to.
* figure out if some of the uninitialised value errors reported in
system libraries on are caused by Memcheck being confused by LLVM
generated code, as per bug #242137
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043
block beyond the original request weren't copied. They are now. This is
important because a program could use malloc_usable_size to gain legitimate
access to those extra bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11956
is a heap profiler that is complementary to Massif. DHAT tracks heap
allocations, and connects which memory accesses are to which blocks.
It can find the following information:
* total allocation and max liveness
* average block lifetime (# instructions between allocation and
freeing)
* average number of reads and writes to each byte in the block
("access ratios")
* average of longest interval of non-access to a block, also
measured in instructions
* which fields of blocks are used a lot, and which aren't
(hot-field profiling)
Using these stats it is possible to identify allocation points with
the following characteristics:
* potential process-lifetime leaks (blocks allocated by the point just
accumulate, and are freed only at the end of the run)
* excessive turnover: points which chew through a lot of heap, even if
it is not held onto for very long
* excessively transient: points which allocate very short lived blocks
* useless or underused allocations: blocks which are allocated but not
completely filled in, or are filled in but not subsequently read.
* blocks which see extended periods of inactivity. Could these
perhaps be allocated later or freed sooner?
* blocks with inefficient layout (hot fields spread out over
multiple cache lines), or with alignment holes
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11431
svn merge -r11143:HEAD svn://svn.valgrind.org/valgrind/branches/MACOSX106
There were some easy-to-resolve conflicts.
Then I had to fix up coregrind/link_tool_exe*.in -- those files had been
added independently on both the trunk and the branch, AFAICT. I just
overwrote the trunk versions with the branch versions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11194
