https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #3 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Stas Sergeev from comment #2) > Created attachment 114889 [details] > 2-process test-case > > Hi, thanks for your reply. > Here is the test-case that does the same > thing but with 2 processes scheme. > Same valgrind error. > While the first test-case represents my real > program more, I really see no difference. For valgrind, there is no way a first valgrind process can track what another valgrind process does to the shared memory. In one single process, I think all would work ok if the memory/file would be mapped only once. It is not very clear to me what is the reason to map twice the same file. At my work, we are using shared memory between several processes. We just declare the shared memory as initialised just after mmap. This avoids false positive (and of course, introduces the risk of a false negative). > > As for the difficulty of fixing this - yes, > I perfectly understand it. While I can think > of some ugly work-arounds (like, for example, > checking if the values have changed, and consider > them initialized in that case), nothing good can > probably be done. How about downgrading the error > to warning if it comes from the shared mem? There is no concept of 'undefined error' and 'undefined warning', and introducing this distinction seems not too desirable (e.g. impact on suppression files, etc). So, if you really have to keep the multiple mmap in a single process, the best way to avoid false positive is to declare the memory as initialised after mmap using VALGRIND_MAKE_MEM_DEFINED or disable error reporting for the mmap-ed address range using VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE -- You are receiving this mail because: You are watching all bug changes.
