https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #16 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Stas Sergeev from comment #15) > (In reply to Philippe Waroquiers from comment #14) > > So, IMO, the easiest is to use the client requests > > Which ones? > I did all the modifications you asked for, they > all in my latest test-case. > > > (the downside of this is that this implies modification of the code). > > No, that downside is that you didn't suggest > any further modifications. :) Here is the new part of the doc describing these false positives: <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> So, the easiest is to use VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE. If you still want to have proper error detection, then you must ensure that whenever your program initialises (or uninitialises) a byte, that the equivalent V bits are modified the same way via VALGRIND_MAKE_MEM_*DEFINED in the other(s) mapping. For example, if you have a read mapping and a write mapping of a page, after each modification via the "write" mapping, you have to 'copy' the V bits from the write mapping to the read mapping. That might not be straightforward to do, in particular if you have multiple threads (you probably need a critical section around the write operations) or processes (this will even be more complex, as you will probably need a side channel to inform all other processes about what was done). This logic is of course application dependent. -- You are receiving this mail because: You are watching all bug changes.
