|
From: Philippe W. <phi...@so...> - 2018-09-13 19:14:47
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=ee5464ce31201049eaff0ac2f8a7101287a6e982 commit ee5464ce31201049eaff0ac2f8a7101287a6e982 Author: Philippe Waroquiers <phi...@sk...> Date: Thu Sep 13 21:13:51 2018 +0200 Improve doc to describe limitations discussed in 398445 (false positive on shared memory) Diff: --- memcheck/docs/mc-manual.xml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index 869a057..514d635 100644 --- 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> |