update

[l4.git] / l4 / pkg / valgrind / src / valgrind-3.6.0-svn / helgrind / docs / hg-manual.xml

diff --git a/l4/pkg/valgrind/src/valgrind-3.6.0-svn/helgrind/docs/hg-manual.xml b/l4/pkg/valgrind/src/valgrind-3.6.0-svn/helgrind/docs/hg-manual.xml
index 08ab3d546073367541bd9ec5391751974e2dd9c0..25c2a69dfc616536847b01fdf02e42fd49a4e3cf 100644 (file)
--- a/l4/pkg/valgrind/src/valgrind-3.6.0-svn/helgrind/docs/hg-manual.xml
+++ b/l4/pkg/valgrind/src/valgrind-3.6.0-svn/helgrind/docs/hg-manual.xml
@@ -229,7 +229,7 @@ Thread #1: lock order "0x7FEFFFAB0 before 0x7FEFFFA80" violated
 <para>When there are more than two locks in the cycle, the error is
 equally serious.  However, at present Helgrind does not show the locks
 involved, so as to avoid flooding you with information.  That could be
-fixed in future.  For example, here is a an example involving a cycle
+fixed in future.  For example, here is an example involving a cycle
 of five locks from a naive implementation the famous Dining
 Philosophers problem
 (see <computeroutput>helgrind/tests/tc14_laog_dinphils.c</computeroutput>).
@@ -262,7 +262,7 @@ are race-free is one of the central difficulties of threaded
 programming.</para>
 
 <para>Reliably detecting races is a difficult problem, and most
-of Helgrind's internals are devoted to do dealing with it.  
+of Helgrind's internals are devoted to dealing with it.  
 We begin with a simple example.</para>
 
 
@@ -955,6 +955,28 @@ unlock(mx)                             unlock(mx)
 <!-- start of xi:include in the manpage -->
 <variablelist id="hg.opts.list">
 
+  <varlistentry id="opt.free-is-write"
+                xreflabel="--free-is-write">
+    <term>
+      <option><![CDATA[--free-is-write=no|yes
+      [default: no] ]]></option>
+    </term>
+    <listitem>
+      <para>When enabled (not the default), Helgrind treats freeing of
+        heap memory as if the memory was written immediately before
+        the free.  This exposes races where memory is referenced by
+        one thread, and freed by another, but there is no observable
+        synchronisation event to ensure that the reference happens
+        before the free.
+      </para>
+      <para>This functionality is new in Valgrind 3.7.0, and is
+        regarded as experimental.  It is not enabled by default
+        because its interaction with custom memory allocators is not
+        well understood at present.  User feedback is welcomed.
+      </para>
+    </listitem>
+  </varlistentry>
+
   <varlistentry id="opt.track-lockorders"
                 xreflabel="--track-lockorders">
     <term>