https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #7 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Stas Sergeev from comment #4) > Created attachment 114906 [details] > 2 processes and VALGRIND_MAKE_MEM_DEFINED > > (In reply to Philippe Waroquiers from comment #3) > > It is not very clear to me what is the reason > > to map twice the same file. > > Mapping file twice may not be needed, but > mapping shared memory twice (which is what > my test-case does) allows you to create the > mem aliases with different access rights. > Consider writing the JIT. I am sure you, > as a valgrind developer, write JIT every > day actually. :) To trap self-modified > code, you would execute the JITted code > in PROT_EXEC window (no PROT_WRITE), and > the JIT itself will access it via > PROT_READ|PROT_WRITE window (very rough > picture, it functions differently of course, > but multiple windows with different perms > are needed). Ok, yes that clarifies. > > But I would suggest to forget this exotic > case and assume I use 2 processes as my > second test-case does. This is because I > simply don't see any difference. If you explain > me why 2 processes+shmem are safe, I guess > I'll deal with the rest on my own. Since > valgrind doesn't know how the actions on > shmem in one process affects another, it > just exactly the same way doesn't know how > writes within a single process can affect > another mem window in the same process. Yes, for sure, valgrind cannot follow what another process does to shared memory. > > > At my work, we are using shared memory between > > several processes. We just declare the shared memory > > as initialised just after mmap. > > See my next test-case where I did exactly > that. I don't think it was needed, as AFAIK > mmap()ed memory is always zeroed and valgrind > knows this already, but I did that to follow > your suggestion. If mmap would necessarily zero out memory, then that would create major difficulties to use shared memory. I think that what the kernel guarantees is that the first process that creates new memory with mmap gets zero-ed memory (otherwise, that would be an info leak from the previous process that used this memory). Initialising yourself the memory via one ptr but accessing it via another mapping is not the same as declaring the memory defined after *each* mmap. In the first case, valgrind can just detect that the memory at ptr1 address is initialised, but it cannot see this initialisation via the second mapping. > > > 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). > > Then you should at least document the > possible sources of false-positives, including > this one. I spent many hours trying to > understand what valgrind is up to. A very > long route was passed to track things back > to the shared memory use (--track-origins > just points to the stack allocation that didn't > give me any clue). If that would have been > documented, I would immediately understand > that I hit exactly that case. Yes, that is a good idea. Do you have a suggestion about the best place to add this piece of information in the documentation ? > > > or disable error reporting for the mmap-ed address > > range using > > VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE > > Thanks. If nothing else, I can do that. > But since I don't want to deal with valgrind > instrumentation headers, I can as well add > an extra initializers just to silence down > the errors. So basically I _will_ find the > ways to silence down the errors, but getting > things improved (or at least documented) on > valgrind side would be a good result after > my many-hours research of those false-positives. :) Yes, the doc must be good, in particular to document (surprising) limitations. -- You are receiving this mail because: You are watching all bug changes.
