From: Philippe Waroquiers Date: Thu, 13 Sep 2018 19:13:51 +0000 (+0200) Subject: Improve doc to describe limitations discussed in 398445 (false positive on shared... X-Git-Tag: VALGRIND_3_14_0~32 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ee5464ce31201049eaff0ac2f8a7101287a6e982;p=thirdparty%2Fvalgrind.git Improve doc to describe limitations discussed in 398445 (false positive on shared memory) --- diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index 869a057657..514d63581f 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. +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 VALGRIND_MAKE_MEM_DEFINED and +VALGRIND_MAKE_MEM_UNDEFINED to inform +Memcheck about what your program does (or what another process does) +to these shared memory mappings. Alternatively, you can also use +VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE. + +