[Valgrind-announce] Valgrind-3.4.0 is available

[Julian S. <js...@ac...>]

We are pleased to announce a new release of Valgrind, version 3.4.0,
available from http://www.valgrind.org.

Valgrind is an open-source suite of simulation based debugging and
profiling tools.  With the tools that come with Valgrind, you can
automatically detect many memory management and threading bugs, which
avoids hours of frustrating bug-hunting, and makes your code more
stable.  You can also perform detailed time and space profiling to
help speed up and slim down your programs.

3.4.0 is a feature release with many significant improvements and the
usual collection of bug fixes.  This release supports X86/Linux,
AMD64/Linux, PPC32/Linux and PPC64/Linux.  See the release notes below
for details.

Our thanks to all those who contribute to Valgrind's development.
This release represents a great deal of time, energy and effort on the
part of many people.

Happy (and productive) debugging and profiling,

-- The Valgrind Developers


Release 3.4.0 (2 January 2009)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.4.0 is a feature release with many significant improvements and the
usual collection of bug fixes.  This release supports X86/Linux,
AMD64/Linux, PPC32/Linux and PPC64/Linux.  Support for recent distros
(using gcc 4.4, glibc 2.8 and 2.9) has been added.

3.4.0 brings some significant tool improvements.  Memcheck can now
report the origin of uninitialised values, the thread checkers
Helgrind and Drd are much improved, and we have a new experimental
tool, exp-Ptrcheck, which is able to detect overruns of stack and
global arrays.  In detail:

* Memcheck is now able to track the origin of uninitialised values.
  When it reports an uninitialised value error, it will try to show
  the origin of the value, as either a heap or stack allocation.
  Origin tracking is expensive and so is not enabled by default.  To
  use it, specify --track-origins=yes.  Memcheck's speed will be
  essentially halved, and memory usage will be significantly
  increased.  Nevertheless it can drastically reduce the effort
  required to identify the root cause of uninitialised value errors,
  and so is often a programmer productivity win, despite running more
  slowly.

* A version (1.4.0) of the Valkyrie GUI, that works with Memcheck in
  3.4.0, will be released shortly.

* Helgrind's race detection algorithm has been completely redesigned
  and reimplemented, to address usability and scalability concerns:

  - The new algorithm has a lower false-error rate: it is much less
    likely to report races that do not really exist.

  - Helgrind will display full call stacks for both accesses involved
    in a race.  This makes it easier to identify the root causes of
    races.

  - Limitations on the size of program that can run have been removed.

  - Performance has been modestly improved, although that is very
    workload-dependent.

  - Direct support for Qt4 threading has been added.

  - pthread_barriers are now directly supported.

  - Helgrind works well on all supported Linux targets.

* The Drd thread debugging tool has seen major improvements:

  - Greatly improved performance and significantly reduced memory
    usage.

  - Support for several major threading libraries (Boost.Thread, Qt4,
    glib, OpenMP) has been added.

  - Support for atomic instructions, POSIX semaphores, barriers and
    reader-writer locks has been added.

  - Works now on PowerPC CPUs too.

  - Added support for printing thread stack usage at thread exit time.

  - Added support for debugging lock contention.

  - Added a manual for Drd.

* A new experimental tool, exp-Ptrcheck, has been added.  Ptrcheck
  checks for misuses of pointers.  In that sense it is a bit like
  Memcheck.  However, Ptrcheck can do things Memcheck can't: it can
  detect overruns of stack and global arrays, it can detect
  arbitrarily far out-of-bounds accesses to heap blocks, and it can
  detect accesses heap blocks that have been freed a very long time
  ago (millions of blocks in the past).

  Ptrcheck currently works only on x86-linux and amd64-linux.  To use
  it, use --tool=exp-ptrcheck.  A simple manual is provided, as part
  of the main Valgrind documentation.  As this is an experimental
  tool, we would be particularly interested in hearing about your
  experiences with it.

* exp-Omega, an experimental instantaneous leak-detecting tool, is no
  longer built by default, although the code remains in the repository
  and the tarball.  This is due to three factors: a perceived lack of
  users, a lack of maintenance, and concerns that it may not be
  possible to achieve reliable operation using the existing design.

* As usual, support for the latest Linux distros and toolchain
  components has been added.  It should work well on Fedora Core 10,
  OpenSUSE 11.1 and Ubuntu 8.10.  gcc-4.4 (in its current pre-release
  state) is supported, as is glibc-2.9.  The C++ demangler has been
  updated so as to work well with C++ compiled by even the most recent
  g++'s.

* You can now use frame-level wildcards in suppressions.  This was a
  frequently-requested enhancement.  A line "..." in a suppression now
  matches zero or more frames.  This makes it easier to write
  suppressions which are precise yet insensitive to changes in
  inlining behaviour.

* 3.4.0 adds support on x86/amd64 for the SSSE3 instruction set.

* Very basic support for IBM Power6 has been added (64-bit processes only).

* Valgrind is now cross-compilable.  For example, it is possible to
  cross compile Valgrind on an x86/amd64-linux host, so that it runs
  on a ppc32/64-linux target.

* You can set the main thread's stack size at startup using the
  new --main-stacksize= flag (subject of course to ulimit settings).
  This is useful for running apps that need a lot of stack space.

* The limitation that you can't use --trace-children=yes together
  with --db-attach=yes has been removed.

* The following bugs have been fixed.  Note that "n-i-bz" stands for
  "not in bugzilla" -- that is, a bug that was reported to us but
  never got a bugzilla entry.  We encourage you to file bugs in
  bugzilla (http://bugs.kde.org/enter_valgrind_bug.cgi) rather than
  mailing the developers (or mailing lists) directly.

  n-i-bz  Make return types for some client requests 64-bit clean
  n-i-bz  glibc 2.9 support
  n-i-bz  ignore unsafe .valgrindrc's (CVE-2008-4865)
  n-i-bz  MPI_Init(0,0) is valid but libmpiwrap.c segfaults
  n-i-bz  Building in an env without gdb gives bogus gdb attach
  92456   Tracing the origin of uninitialised memory
  106497  Valgrind does not demangle some C++ template symbols
  162222  ==106497
  151612  Suppression with "..." (frame-level wildcards in .supp files)
  156404  Unable to start oocalc under memcheck on openSUSE 10.3 (64-bit)
  159285  unhandled syscall:25 (stime, on x86-linux)
  159452  unhandled ioctl 0x8B01 on "valgrind iwconfig"
  160954  ppc build of valgrind crashes with illegal instruction (isel)
  160956  mallinfo implementation, w/ patch
  162092  Valgrind fails to start gnome-system-monitor
  162819  malloc_free_fill test doesn't pass on glibc2.8 x86
  163794  assertion failure with "--track-origins=yes"
  163933  sigcontext.err and .trapno must be set together
  163955  remove constraint !(--db-attach=yes && --trace-children=yes)
  164476  Missing kernel module loading system calls
  164669  SVN regression: mmap() drops posix file locks
  166581  Callgrind output corruption when program forks
  167288  Patch file for missing system calls on Cell BE
  168943  unsupported scas instruction pentium
  171645  Unrecognised instruction (MOVSD, non-binutils encoding)
  172417  x86->IR: 0x82 ...
  172563  amd64->IR: 0xD9 0xF5  -  fprem1
  173099  .lds linker script generation error
  173177  [x86_64] syscalls: 125/126/179 (capget/capset/quotactl)
  173751  amd64->IR: 0x48 0xF 0x6F 0x45 (even more redundant prefixes)
  174532  == 173751
  174908  --log-file value not expanded correctly for core file
  175044  Add lookup_dcookie for amd64
  175150  x86->IR: 0xF2 0xF 0x11 0xC1 (movss non-binutils encoding)

Developer-visible changes:

* Valgrind's debug-info reading machinery has been majorly overhauled.
  It can now correctly establish the addresses for ELF data symbols,
  which is something that has never worked properly before now.

  Also, Valgrind can now read DWARF3 type and location information for
  stack and global variables.  This makes it possible to use the
  framework to build tools that rely on knowing the type and locations
  of stack and global variables, for example exp-Ptrcheck.

  Reading of such information is disabled by default, because most
  tools don't need it, and because it is expensive in space and time.
  However, you can force Valgrind to read it, using the
  --read-var-info=yes flag.  Memcheck, Helgrind and DRD are able to
  make use of such information, if present, to provide source-level
  descriptions of data addresses in the error messages they create.

(3.4.0.RC1:  24 Dec 2008, vex r1878, valgrind r8882).
(3.4.0:       3 Jan 2009, vex r1878, valgrind r8899).