https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #4 from Stas Sergeev <s...@list.ru> --- Created attachment 114906 --> https://bugs.kde.org/attachment.cgi?id=114906&action=edit 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). 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. > 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. > 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. > 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. :) -- You are receiving this mail because: You are watching all bug changes.
