https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #18 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Stas Sergeev from comment #17) > (In reply to Philippe Waroquiers from comment #16) > > 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). > Exactly, that's the point. > You need a side-channel that also knows > about the relationship between the pointers > to shm in different processes - something > only the kernel knows about normally (a bit > simpler if shm is mapped before fork() - then > the pointers are equal, but this is not always > the case). > Thant's why I think VALGRIND_MAKE_MEM_DEFINED > doesn't actually work for this case, and yet > you suggested it all along the way here (and > I was updating the test-case) and also in the > docs. The above is exactly what we do with shared memory at my day job, so, it works in at least one case :). But depending on the application, it might be (very) difficult to be precise. Then just be less precise: e.g. before each access to shared memory, declare it initialised. That will for sure work. > So I think there is some mistake. > This all seems to suggest it might be better > to enable the errors from shm with some extra > command-line switch, leaving it disabled by > default... When a 'usage of undefined' bit is detected, it is not known anymore that this undefined value came from (or through) shared memory, so it is not clear to me how we could implement this, and if we could, what would be the impact on the performance. At best, it would mean to do something like --track-origin=yes and have 'shared memory' origin having priority over other origins. Which mean that we would lose the real origin of a bug in case it is a real bug not originating from shared memory. Sorry I cannot help you more on that, I would have liked to propose something better. -- You are receiving this mail because: You are watching all bug changes.
