Update. Sheesh -- did we really change that much stuff in just seven
months?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10816 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/NEWS b/NEWS
index 363dc92..49e7172 100644
--- a/NEWS
+++ b/NEWS
@@ -1,25 +1,56 @@
-Release 3.5.0 ([Julian] XXX)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-3.5.0 is a feature release with many significant improvements and the
-usual collection of bug fixes. The main improvement is that Valgrind now
-works on Mac OS X. Also, there is a new experimental tool, exp-BBV, which
-will be of use to computer architecture researchers. Furthermore,
-Valgrind's text output has change in various ways, and Memcheck's leak
-checker has been improved and Valgrind's output has changed somewhat. In
-detail:
+Release 3.5.0 (XXX August 2009)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* Valgrind now runs on Mac OS X. (Note that Mac OS X is sometimes called
- "Darwin" because that is the name of the OS core.)
+3.5.0 is a feature release with many significant improvements and the
+usual collection of bug fixes. The main improvement is that Valgrind
+now works on Mac OS X.
+
+This release supports X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux
+and X86/Darwin. Support for recent distros and toolchain components
+(glibc 2.10, gcc 4.5) has been added.
+
+ -------------------------
+
+Here is a short summary of the changes. Details are shown further
+down:
+
+* support for Mac OS X 10.5.x
+
+* improvements and simplifications to Memcheck's leak checker
+
+* clarification and simplifications in various aspects of Valgrind's
+ text output
+
+* XML output for Helgrind and Ptrcheck
+
+* performance and stability improvements for Helgrind and DRD
+
+* genuinely atomic support for x86/amd64/ppc atomic instructions
+
+* a new experimental tool, BBV, useful for computer architecture
+ research
+
+* improved Wine support, including ability to read Windows PDB
+ debuginfo
+
+ -------------------------
+
+Here are details of the above changes, plus descriptions of many other
+minor changes.
+
+
+* Valgrind now runs on Mac OS X. (Note that Mac OS X is sometimes
+ called "Darwin" because that is the name of the OS core.)
Supported machines:
- x86 machines are supported fairly well.
- - AMD64 (a.k.a. x86-64) are supported, but not as well. In particular,
- start-up is slow.
+ - amd64 (a.k.a. x86-64) are supported, but not as well. In
+ particular, start-up is slow.
- - Older PowerPC machines are not supported.
+ - PowerPC machines are not supported.
- It requires Mac OS X 10.5 Leopard or later. Porting to 10.4 is not
planned because it would require work and 10.4 is only becoming less
@@ -33,27 +64,49 @@
- --db-attach=yes.
- - If you have Rogue Amoeba's "Instant Hijack" program installed, Valgrind
- will fail with a SIGTRAP at start-up. This is apparently Instant
- Hijack's fault. See https://bugs.kde.org/show_bug.cgi?id=193917 for
- details and a simple work-around.
+ - If you have Rogue Amoeba's "Instant Hijack" program installed,
+ Valgrind will fail with a SIGTRAP at start-up. See
+ https://bugs.kde.org/show_bug.cgi?id=193917 for details and a
+ simple work-around.
Usage notes:
- - You will likely find --dsymutil=yes a useful option, as error messages may
- be imprecise without it.
+ - You will likely find --dsymutil=yes a useful option, as error
+ messages may be imprecise without it.
- - The Mac OS X support is new and therefore will be less robust than the
+ - Mac OS X support is new and therefore will be less robust than the
Linux support. Please report any bugs you find.
+ - Threaded programs may run more slowly than on Linux.
+
Many thanks to Greg Parker for developing this port over several years.
-* A new experimental tool, BBV, has been added. BBV generates basic block
- vectors for use with the SimPoint analysis tool, which allows a program's
- overall behaviour to be approximated by running only a fraction of it.
- This is useful for computer architecture researchers. You can run BBV by
- specifying --tool=exp-bbv (the "exp-" prefix is short for "experimental").
- BBV was written by Vince Weaver.
+
+* Memcheck's leak checker has been improved.
+
+ - The results for --leak-check=summary now match the summary results
+ for --leak-check=full. Previously they could differ because
+ --leak-check=summary counted "indirectly lost" blocks and
+ "suppressed" blocks as "definitely lost".
+
+ - Blocks that are only reachable via at least one interior-pointer,
+ but are directly pointed to by a start-pointer, were previously
+ marked as "still reachable". They are now correctly marked as
+ "possibly lost".
+
+ - The default value for the --leak-resolution option has been
+ changed from "low" to "high". In general, this means that more
+ leak reports will be produced, but each leak report will describe
+ fewer leaked blocks.
+
+ - With --leak-check=full, "definitely lost" and "possibly lost"
+ leaks are now considered as proper errors, ie. they are counted
+ for the "ERROR SUMMARY" and affect the behaviour of
+ --error-exitcode. These leaks are not counted as errors if
+ --leak-check=summary is specified, however.
+
+ - Documentation for the leak checker has been improved.
+
* Various aspects of Valgrind's text output have changed.
@@ -61,36 +114,23 @@
includes the command being run, which makes it easier to use
--trace-children=yes. An example:
-==3050== Memcheck, a memory error detector.
-==3050== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
-==3050== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
-==3050== Command: ls -l
-
- Valgrind's shut-down messages have also changed. This is most
- noticeable with Memcheck, where the leak summary now occurs before the
- error summary. This change was necessary to allow leaks to be counted
- as proper errors (see the description of the leak checker changes below
- for more details). An example:
+ noticeable with Memcheck, where the leak summary now occurs before
+ the error summary. This change was necessary to allow leaks to be
+ counted as proper errors (see the description of the leak checker
+ changes above for more details). This was also necessary to fix a
+ longstanding bug in which uses of suppressions against leaks were
+ not "counted", leading to difficulties in maintaining suppression
+ files (XXXX bug number).
-==16663== HEAP SUMMARY:
-==16663== in use at exit: 15,090 bytes in 17 blocks
-==16663== total heap usage: 17 allocs, 0 frees, 15,090 bytes allocated
-==16663==
-==16663== LEAK SUMMARY:
-==16663== definitely lost: 0 bytes in 0 blocks
-==16663== indirectly lost: 0 bytes in 0 blocks
-==16663== possibly lost: 0 bytes in 0 blocks
-==16663== still reachable: 10,694 bytes in 9 blocks
-==16663== suppressed: 4,396 bytes in 8 blocks
-==16663== Rerun with --leak-check=full to see details of leaked memory
-==16663==
-==16663== For counts of detected and suppressed errors, rerun with: -v
-==16663== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+ - Behavior of -v has changed. In previous versions, -v printed out
+ a mixture of marginally-user-useful information, and tool/core
+ statistics. The statistics printing has now been moved to its own
+ flag, --stats=yes. This means -v is less verbose and more likely
+ to convey useful end-user information.
- - [Julian] XXX: XML output has changed... along with how --xml=yes works.
-
- - The format of some (non-XML) stack trace entries has changed a little.
- Previously there were six possible forms:
+ - The format of some (non-XML) stack trace entries has changed a
+ little. Previously there were six possible forms:
0x80483BF: really (a.c:20)
0x80483BF: really (in /foo/a.out)
@@ -99,8 +139,8 @@
0x80483BF: ??? (a.c:20)
0x80483BF: ???
- The third and fourth of these forms have been made more consistent with
- the others. The six possible forms are now:
+ The third and fourth of these forms have been made more consistent
+ with the others. The six possible forms are now:
0x80483BF: really (a.c:20)
0x80483BF: really (in /foo/a.out)
@@ -109,65 +149,119 @@
0x80483BF: ??? (a.c:20)
0x80483BF: ???
- Stack traces produced when --xml=yes is specified are different and
- unchanged.
+ Stack traces produced when --xml=yes is specified are different
+ and unchanged.
-* Memcheck's leak checker has been improved.
- - The results for --leak-check=summary now match the summary results for
- --leak-check=full. Previously they could differ because
- --leak-check=summary counted "indirectly lost" blocks and "suppressed"
- blocks as "definitely lost".
+* Helgrind and Ptrcheck now support XML output, so they can be used
+ from GUI tools. Also, the XML output mechanism has been
+ overhauled.
- - Blocks that are only reachable via at least one interior-pointer, but
- are directly pointed to by a start-pointer, were previously marked as
- "still reachable". They are now correctly marked as "possibly lost".
+ - the XML format has been overhauled and generalised, so it is more
+ suitable for error reporting tools in general. The Memcheck
+ specific aspects of it have been removed. The new format, which
+ is an evolution of the old format, is described in
+ docs/internals/xml-output-protocol4.txt.
- - The default value for the --leak-resolution option has been changed from
- "low" to "high". In general, this means that more leak reports will be
- produced, but each leak report will describe fewer leaked blocks.
+ - Memcheck has been updated to use the new format.
- - With --leak-check=full, "definitely lost" and "possibly lost" leaks are
- now considered as proper errors, ie. they are counted for the "ERROR
- SUMMARY" and affect the behaviour of --error-exitcode. These leaks are
- not counted as errors if --leak-check=summary is specified, however.
+ - Helgrind and Ptrcheck are now able to emit output in this format.
- - The documentation for the leak checker has been improved.
+ - The XML output mechanism has been overhauled. XML is now output
+ to its own file descriptor, which means that:
-* [Julian] XXX: something about improved Wine support?
+ * Valgrind can output text and XML independently.
-* A new Memcheck client request VALGRIND_COUNT_LEAK_BLOCKS has been added.
- It is similar to VALGRIND_COUNT_LEAKS but counts blocks instead of bytes.
+ * The longstanding problem of XML output being corrupted by
+ unexpected un-tagged text messages is solved.
-* The Valgrind client requests VALGRIND_PRINTF and VALGRIND_PRINTF_BACKTRACE
- have been changed slightly. Previously, the string was always printed
- immediately on its own line. Now, the string will be added to a buffer
- but not printed until a newline is encountered, or other Valgrind output
- is printed (note that for VALGRIND_PRINTF_BACKTRACE, the back-trace itself
- is considered "other Valgrind output"). This allows you to use multiple
- VALGRIND_PRINTF calls to build up a single output line, and also to print
- multiple output lines with a single request (by embedding multiple
- newlines in the string).
+ As before, the destination for text output is specified using
+ --log-file=, --log-fd= or --log-socket=.
-* [Julian] XXX: Atomic instructions are now handled properly...
+ As before, XML output for a tool is enabled using --xml=yes.
-* The graphs drawn by Massif's ms_print program have changed slightly:
+ Because there's a new XML output channel, the XML output
+ destination is now specified by --xml-file=, --xml-fd= or
+ --xml-socket=.
- - The half-height chars '.' and ',' are no longer drawn, because they are
- confusing. The --y option can be used if the default y-resolution is
- not high enough.
+ Initial feedback has shown this causes some confusion. To
+ clarify, the two envisaged usage scenarios are:
- - Horizontal lines are now drawn after the top of a snapshot if there is a
- gap until the next snapshot. This makes it clear that the memory
- usage has not dropped to zero between snapshots.
+ (1) Normal text output. In this case, do not specify --xml=yes
+ nor any of --xml-file=, --xml-fd= or --xml-socket=.
+
+ (2) XML output. In this case, specify --xml=yes, and one of
+ --xml-file=, --xml-fd= or --xml-socket= to select the XML
+ destination, one of --log-file=, --log-fd= or --log-socket=
+ to select the destination for any remaining text messages,
+ and, importantly, -q.
+
+ -q makes Valgrind completely silent on the text channel,
+ except in the case of critical failures, such as Valgrind
+ itself segfaulting, or failing to read debugging information.
+ Hence, in this scenario, it suffices to check whether or not
+ any output appeared on the text channel. If yes, then it is
+ likely to be a critical error which should be brought to the
+ attention of the user. If no (the text channel produced no
+ output) then it can be assumed that the run was successful.
+
+ This allows GUIs to make the critical distinction they need to
+ make (did the run fail or not?) without having to search or
+ filter the text output channel in any way.
+
+ It is also recommended to use --child-silent-after-fork=yes in
+ scenario (2).
+
+
+* Improvements and changes in Helgrind:
+
+ - XML output, as described above
+
+ - Checks for consistent association between pthread condition
+ variables and their associated mutexes are now performed.
+
+ - pthread_spinlock functions are supported.
+
+ - Modest performance improvements.
+
+ - Initial (skeletal) support for describing the behaviour of
+ non-POSIX synchronisation objects through ThreadSanitizer
+ compatible ANNOTATE_* macros.
+
+ - More controllable tradeoffs between performance and the level of
+ detail of "previous" accesses in a race. There are now three
+ settings:
+
+ * --history-level=full. This is the default, and was also the
+ default in 3.4.x. It shows both stacks involved in a race, but
+ requires a lot of memory and can be very slow in programs that
+ do many inter-thread synchronisation events.
+
+ * --history-level=none. This only shows the later stack involved
+ in a race. This can be much faster than --history-level=full,
+ but makes it much more difficult to find the other access
+ involved in the race.
+
+ The new intermediate setting is
+
+ * --history-level=approx
+
+ For the earlier (other) access, two stacks are presented. The
+ earlier access is guaranteed to be somewhere in between the two
+ program points denoted by those stacks. This is not as useful
+ as showing the exact stack for the previous access (as per
+ --history-level=full), but it is better than nothing, and it's
+ almost as fast as --history-level=none.
+
* New features and improvements in DRD:
- - The error messages printed by DRD are now easier to interpret. Instead of
- using two different numbers to identify each thread (Valgrind thread ID and
- DRD thread ID), DRD does now identify threads via a single number (the DRD
- thread ID). Furthermore "first observed at" information is now printed for
- all error messages related to synchronization objects.
+ - The error messages printed by DRD are now easier to interpret.
+ Instead of using two different numbers to identify each thread
+ (Valgrind thread ID and DRD thread ID), DRD does now identify
+ threads via a single number (the DRD thread ID). Furthermore
+ "first observed at" information is now printed for all error
+ messages related to synchronization objects.
- Added support for named semaphores (sem_open() and sem_close()).
@@ -175,62 +269,143 @@
pthread_barrier_destroy() calls are now reported.
- Added support for custom allocators through the macros
- VALGRIND_MALLOCLIKE_BLOCK() VALGRIND_FREELIKE_BLOCK() (defined in
- in <valgrind/valgrind.h>). An alternative for these two macros is the
- new client request VG_USERREQ__DRD_CLEAN_MEMORY (defined in
+ VALGRIND_MALLOCLIKE_BLOCK() VALGRIND_FREELIKE_BLOCK() (defined in
+ in <valgrind/valgrind.h>). An alternative for these two macros is
+ the new client request VG_USERREQ__DRD_CLEAN_MEMORY (defined in
<valgrind/drd.h>).
- - Added support for annotating non-POSIX synchronization objects through
- several new ANNOTATE_*() macros.
+ - Added support for annotating non-POSIX synchronization objects
+ through several new ANNOTATE_*() macros.
- - OpenMP: added support for the OpenMP runtime (libgomp) included with gcc
- versions 4.3.0 and 4.4.0.
+ - OpenMP: added support for the OpenMP runtime (libgomp) included
+ with gcc versions 4.3.0 and 4.4.0.
- Faster operation.
- Added two new command-line options (--first-race-only and
--segment-merging-interval).
-* Something that happened in 3.4.0, but wasn't clearly announced: the
- option --read-var-info can be used by some tools (Memcheck, Helgrind and
- DRD). When enabled, it makes those tools run more slowly and increases
- memory consumption, but descriptions of data addresses in error messages
- become more detailed.
-* exp-Omega, an experimental instantaneous leak-detecting tool, was disabled
- in 3.4.0 due to a lack of interest and maintenance, although the source
- code was still in the distribution. The source code has now been removed
- from the distribution. For anyone interested, the removal occurred in SVN
- revision r10247.
+* Genuinely atomic support for x86/amd64/ppc atomic instructions
+
+ Valgrind will now preserve (memory-access) atomicity of LOCK-
+ prefixed x86/amd64 instructions, and any others implying a global
+ bus lock. Ditto for PowerPC l{w,d}arx/st{w,d}cx. instructions.
+
+ This means that Valgrinded processes will "play nicely" in
+ situations where communication with other processes, or the kernel,
+ is done through shared memory and coordinated with such atomic
+ instructions. Prior to this change, such arrangements usually
+ resulted in hangs, races or other synchronisation failures, because
+ Valgrind did not honour atomicity of such instructions.
+
+
+* A new experimental tool, BBV, has been added. BBV generates basic
+ block vectors for use with the SimPoint analysis tool, which allows
+ a program's overall behaviour to be approximated by running only a
+ fraction of it. This is useful for computer architecture
+ researchers. You can run BBV by specifying --tool=exp-bbv (the
+ "exp-" prefix is short for "experimental"). BBV was written by
+ Vince Weaver.
+
+
+* Modestly improved support for running Windows applications under
+ Wine. In particular, initial support for reading Windows .PDB debug
+ information has been added.
+
+
+* A new Memcheck client request VALGRIND_COUNT_LEAK_BLOCKS has been
+ added. It is similar to VALGRIND_COUNT_LEAKS but counts blocks
+ instead of bytes.
+
+
+* The Valgrind client requests VALGRIND_PRINTF and
+ VALGRIND_PRINTF_BACKTRACE have been changed slightly. Previously,
+ the string was always printed immediately on its own line. Now, the
+ string will be added to a buffer but not printed until a newline is
+ encountered, or other Valgrind output is printed (note that for
+ VALGRIND_PRINTF_BACKTRACE, the back-trace itself is considered
+ "other Valgrind output"). This allows you to use multiple
+ VALGRIND_PRINTF calls to build up a single output line, and also to
+ print multiple output lines with a single request (by embedding
+ multiple newlines in the string).
+
+
+* The graphs drawn by Massif's ms_print program have changed slightly:
+
+ - The half-height chars '.' and ',' are no longer drawn, because
+ they are confusing. The --y option can be used if the default
+ y-resolution is not high enough.
+
+ - Horizontal lines are now drawn after the top of a snapshot if
+ there is a gap until the next snapshot. This makes it clear that
+ the memory usage has not dropped to zero between snapshots.
+
+
+* Something that happened in 3.4.0, but wasn't clearly announced: the
+ option --read-var-info=yes can be used by some tools (Memcheck,
+ Helgrind and DRD). When enabled, it causes Valgrind to read DWARF3
+ variable type and location information. This makes those tools
+ start up more slowly and increases memory consumption, but
+ descriptions of data addresses in error messages become more
+ detailed.
+
+
+* exp-Omega, an experimental instantaneous leak-detecting tool, was
+ disabled in 3.4.0 due to a lack of interest and maintenance,
+ although the source code was still in the distribution. The source
+ code has now been removed from the distribution. For anyone
+ interested, the removal occurred in SVN revision r10247.
+
* Some changes have been made to the build system.
- - VEX/ is now integrated properly into the build system. This means that
- dependency tracking within VEX/ now works properly, "make install" will
- work without requiring "make" before it, and parallel builds
- (ie. 'make -j') now work (previously a .NOTPARALLEL directive was used
- to serialize builds, ie. 'make -j' was effectively ignored).
+ - VEX/ is now integrated properly into the build system. This means
+ that dependency tracking within VEX/ now works properly, "make
+ install" will work without requiring "make" before it, and
+ parallel builds (ie. 'make -j') now work (previously a
+ .NOTPARALLEL directive was used to serialize builds, ie. 'make -j'
+ was effectively ignored).
- - The --with-vex configure option has been removed. It was of little use
- and removing it simplified the build system.
+ - The --with-vex configure option has been removed. It was of
+ little use and removing it simplified the build system.
- - The location of some install files has changed. This should not affect
- most users. Those who might be affected:
+ - The location of some install files has changed. This should not
+ affect most users. Those who might be affected:
* For people who use Valgrind with MPI programs, the installed
- libmpiwrap.so library has moved from $(INSTALL)/<platform>/libmpiwrap.so
- to $(INSTALL)/libmpiwrap-<platform>.so.
+ libmpiwrap.so library has moved from
+ $(INSTALL)/<platform>/libmpiwrap.so to
+ $(INSTALL)/libmpiwrap-<platform>.so.
- * For people who distribute standalone Valgrind tools, the installed
- libraries such as $(INSTALL)/<platform>/libcoregrind.a have moved to
- $(INSTALL)/libcoregrind-<platform>.a.
+ * For people who distribute standalone Valgrind tools, the
+ installed libraries such as $(INSTALL)/<platform>/libcoregrind.a
+ have moved to $(INSTALL)/libcoregrind-<platform>.a.
- These changes simplified the build system.
+ These changes simplify the build system.
- - Previously, all the distributed suppression (*.supp) files were installed.
- Now, only default.supp is installed. This should not affect users as the
- other installed suppression files were not read; the fact that they
- were installed was a mistake.
+ - Previously, all the distributed suppression (*.supp) files were
+ installed. Now, only default.supp is installed. This should not
+ affect users as the other installed suppression files were not
+ read; the fact that they were installed was a mistake.
+
+
+* KNOWN LIMITATIONS:
+
+ - Memcheck is unusable with the Intel compiler suite version 11.1,
+ when it generates code for SSE2-and-above capable targets. This
+ is because of icc's use of highly optimised inlined strlen
+ implementations. It causes Memcheck to report huge numbers of
+ false errors even in simple programs. Helgrind and DRD may also
+ have problems.
+
+ Versions 11.0 and earlier may be OK, but this has not been
+ properly tested.
+
+
+
+XXX a number of bugs in Callgrind / KCachegrind have been fixed. (?)
+
187048 DRD - the mutex attribute PTHREAD_PROCESS_SHARED is now
interpreted correctly.
@@ -251,6 +426,9 @@
XXX: more bugs listed...
XXX: dates and versions of RCs and final release
+(3.5.0.RC1: XX Aug 2009, vex rXXXX, valgrind rXXXX).
+(3.5.0: XX Aug 2009, vex rXXXX, valgrind rXXXX).
+
Release 3.4.1 (28 February 2009)