[Valgrind-announce] Valgrind-3.0.0 (for x86 and amd64) is available

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

We are pleased to announce a new release of Valgrind, version 3.0.0.
It is 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 bugs, avoiding hours of
frustrating bug-hunting, and make your code more stable.  You can also
perform detailed time and space profiling to help speed up and slim
down your programs.

3.0.0 is the first Valgrind to support both x86-linux and amd64-linux.
Support for ppc32-linux is also integrated but does not work well
enough to be useful yet.  There have been many other improvements and
refinements relative to the 2.4.X line.  The attached release notes
detail what is new in 3.0.0.

Many thanks to all those who contributed 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.0.0 (3 August 2005)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.0.0 is a major overhaul of Valgrind.  The most significant user
visible change is that Valgrind now supports architectures other than
x86.  The new architectures it supports are AMD64 and PPC32, and the
infrastructure is present for other architectures to be added later.

AMD64 support works well, but has some shortcomings:

- It generally won't be as solid as the x86 version.  For example,
  support for more obscure instructions and system calls may be missing.
  We will fix these as they arise.

- Address space may be limited; see the point about
  position-independent executables below.

- If Valgrind is built on an AMD64 machine, it will only run 64-bit
  executables.  If you want to run 32-bit x86 executables under Valgrind
  on an AMD64, you will need to build Valgrind on an x86 machine and
  copy it to the AMD64 machine.  And it probably won't work if you do
  something tricky like exec'ing a 32-bit program from a 64-bit program
  while using --trace-children=yes.  We hope to improve this situation
  in the future.

The PPC32 support is very basic.  It may not work reliably even for
small programs, but it's a start.  Many thanks to Paul Mackerras for
his great work that enabled this support.  We are working to make
PPC32 usable as soon as possible.

Other user-visible changes:

- Valgrind is no longer built by default as a position-independent
  executable (PIE), as this caused too many problems.

  Without PIE enabled, AMD64 programs will only be able to access 2GB of
  address space.  We will fix this eventually, but not for the moment.
  
  Use --enable-pie at configure-time to turn this on.

- Support for programs that use stack-switching has been improved.  Use
  the --max-stackframe flag for simple cases, and the
  VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and
  VALGRIND_STACK_CHANGE client requests for trickier cases.

- Support for programs that use self-modifying code has been improved,
  in particular programs that put temporary code fragments on the stack.
  This helps for C programs compiled with GCC that use nested functions,
  and also Ada programs.  This is controlled with the --smc-check
  flag, although the default setting should work in most cases.

- Output can now be printed in XML format.  This should make it easier
  for tools such as GUI front-ends and automated error-processing
  schemes to use Valgrind output as input.  The --xml flag controls this.
  As part of this change, ELF directory information is read from executables,
  so absolute source file paths are available if needed.

- Programs that allocate many heap blocks may run faster, due to
  improvements in certain data structures.

- Addrcheck is currently not working.  We hope to get it working again
  soon.  Helgrind is still not working, as was the case for the 2.4.0
  release.

- The JITter has been completely rewritten, and is now in a separate
  library, called Vex.  This enabled a lot of the user-visible changes,
  such as new architecture support.  The new JIT unfortunately translates
  more slowly than the old one, so programs may take longer to start.
  We believe the code quality is produces is about the same, so once
  started, programs should run at about the same speed.  Feedback about
  this would be useful.

  On the plus side, Vex and hence Memcheck tracks value flow properly
  through floating point and vector registers, something the 2.X line
  could not do.  That means that Memcheck is much more likely to be
  usably accurate on vectorised code.

- There is a subtle change to the way exiting of threaded programs
  is handled.  In 3.0, Valgrind's final diagnostic output (leak check,
  etc) is not printed until the last thread exits.  If the last thread
  to exit was not the original thread which started the program, any
  other process wait()-ing on this one to exit may conclude it has
  finished before the diagnostic output is printed.  This may not be
  what you expect.  2.X had a different scheme which avoided this
  problem, but caused deadlocks under obscure circumstances, so we
  are trying something different for 3.0.

- Small changes in control log file naming which make it easier to
  use valgrind for debugging MPI-based programs.  The relevant
  new flags are --log-file-exactly= and --log-file-qualifier=.

- As part of adding AMD64 support, DWARF2 CFI-based stack unwinding
  support was added.  In principle this means Valgrind can produce
  meaningful backtraces on x86 code compiled with -fomit-frame-pointer
  providing you also compile your code with -fasynchronous-unwind-tables.

- The documentation build system has been completely redone.
  The documentation masters are now in XML format, and from that
  HTML, PostScript and PDF documentation is generated.  As a result
  the manual is now available in book form.  Note that the
  documentation in the source tarballs is pre-built, so you don't need
  any XML processing tools to build Valgrind from a tarball.

Changes that are not user-visible:

- The code has been massively overhauled in order to modularise it.
  As a result we hope it is easier to navigate and understand.

- Lots of code has been rewritten.

BUGS FIXED:

110046  sz == 4 assertion failed 
109810  vex amd64->IR: unhandled instruction bytes: 0xA3 0x4C 0x70 0xD7
109802  Add a plausible_stack_size command-line parameter ?
109783  unhandled ioctl TIOCMGET (running hw detection tool discover) 
109780  unhandled ioctl BLKSSZGET (running fdisk -l /dev/hda)
109718  vex x86->IR: unhandled instruction: ffreep 
109429  AMD64 unhandled syscall: 127 (sigpending)
109401  false positive uninit in strchr from ld-linux.so.2
109385  "stabs" parse failure 
109378  amd64: unhandled instruction REP NOP
109376  amd64: unhandled instruction LOOP Jb 
109363  AMD64 unhandled instruction bytes 
109362  AMD64 unhandled syscall: 24 (sched_yield)
109358  fork() won't work with valgrind-3.0 SVN
109332  amd64 unhandled instruction: ADC Ev, Gv
109314  Bogus memcheck report on amd64
108883  Crash; vg_memory.c:905 (vgPlain_init_shadow_range):
        Assertion `vgPlain_defined_init_shadow_page()' failed.
108349  mincore syscall parameter checked incorrectly 
108059  build infrastructure: small update
107524  epoll_ctl event parameter checked on EPOLL_CTL_DEL
107123  Vex dies with unhandled instructions: 0xD9 0x31 0xF 0xAE
106841  auxmap & openGL problems
106713  SDL_Init causes valgrind to exit
106352  setcontext and makecontext not handled correctly 
106293  addresses beyond initial client stack allocation 
        not checked in VALGRIND_DO_LEAK_CHECK
106283  PIE client programs are loaded at address 0
105831  Assertion `vgPlain_defined_init_shadow_page()' failed.
105039  long run-times probably due to memory manager 
104797  valgrind needs to be aware of BLKGETSIZE64
103594  unhandled instruction: FICOM
103320  Valgrind 2.4.0 fails to compile with gcc 3.4.3 and -O0
103168  potentially memory leak in coregrind/ume.c 
102039  bad permissions for mapped region at address 0xB7C73680
101881  weird assertion problem
101543  Support fadvise64 syscalls
75247   x86_64/amd64 support (the biggest "bug" we have ever fixed)

(3.0RC1: 27 July   05, vex r1303, valgrind r4283).
(3.0.0:   3 August 05, vex r1313, valgrind r4316).