Improve doc to describe limitations discussed in 398445 (false positive on shared...

diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml
index 869a05765788e07fe3336416ddf21843ff8c4996..514d63581f1a79703132d059e317378d512dc96b 100644 (file)
--- a/memcheck/docs/mc-manual.xml
+++ b/memcheck/docs/mc-manual.xml
@@ -1568,6 +1568,23 @@ is necessary.  This allows GCC to copy
 warning will only be emitted if the uninitialised values are later
 used.</para>
 
+<para>As explained above, Memcheck maintains 8 V bits for each byte in your
+process, including for bytes that are in shared memory.  However, the same piece
+of shared memory can be mapped multiple times, by several processes or even by
+the same process (for example, if the process wants a read-only and a read-write
+mapping of the same page).  For such multiple mappings, Memcheck tracks the V
+bits for each mapping independently. This can lead to false positive errors, as
+the shared memory can be initialised via a first mapping, and accessed via
+another mapping.  The access via this other mapping will have its own V bits,
+which have not been changed when the memory was initialised via the first
+mapping.  The bypass for these false positives is to use Memcheck's client
+requests <varname>VALGRIND_MAKE_MEM_DEFINED</varname> and
+<varname>VALGRIND_MAKE_MEM_UNDEFINED</varname> to inform
+Memcheck about what your program does (or what another process does)
+to these shared memory mappings. Alternatively, you can also use
+<varname>VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE</varname>.
+</para>
+
 </sect2>