Valgrind should correctly translate the memory fence instructions into platform-specific memory fences that are at least not weaker, otherwise every synchronization algorithm would've been broken under Valgrind. On amd64 Valgrind creates an IRStmt_MBE(Imbe_Fence) for sfence/lfence/mfcence (see VEX/priv/guest_amd64_toIR.c), which is later translated to mfence when executing the code (see VEX/priv/host_amd64_isel.c).
(On the related note, I wanted to try Knot DNS under a couple of tools, but failed to find any documentation for running the tests) On Mon, Aug 18, 2014 at 5:09 PM, Jan Včelák <jan.vce...@nic.cz> wrote: > Hello list, > > we develop an authoritative DNS server called Knot DNS and we use the > userspace-rcu library [1] for synchronization. The library implements the > synchronization by inserting appropriate sfence/lfence/mfcence instructions > and some reference counting around. > > Currently, we are trying to track down an invalid read reported by Valgrind. > The problem appears very rarely and it's quite difficult to reproduce. > Valgrind claims that a previously freed memory is being read. However we quite > sure that the synchronization is correct and that this problem should not > happen. > > Does Valgrind support the mentioned memory barrier instructions? > > I'm not rejecting that there is a problem in our code, but I want to make sure > that we are chasing a real bug. > > Thanks and regards > > Jan > > [1] http://lttng.org/urcu > > ------------------------------------------------------------------------------ > _______________________________________________ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Alexander Potapenko Software Engineer Google Moscow ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
