OK. Then it is likely that there is a bug in our software. As for the tests - it is a bit complicated. But if you are willing to spend some time on it, we would be very happy. :-)
Get latest Knot DNS from git: $ git clone https://gitlab.labs.nic.cz/labs/knot.git Compile the server. We hit the problem with the following configuration: $ autoreconf -fi $ export CC=gcc $ export CFLAGS="-O0 -g -j4" $ ./configure --enable-recvmmsg=no \ --enable-lto=no \ --disable-fastparser \ --disable-shared \ --enable-static $ make $ make check Setup environment for functional tests. You will need Python >= 3.3, BIND 9, lsof, and a few Python modules, which can be installed using pip: $ cd tests-extra $ pip install -r requirements.txt To run the occasionally failing test, execute: $ ./runtests.py ixfr/knot_bind The test establishes Knot DNS as a master server, BIND as a slave and performs simple zone transfer. Our testing machine is 4-core Intel Xeon machine, with 64-bit Linux (Ubuntu 13.10. and 3.11.0-18-generic kernel). I run the test case several times without Valgrind with address sanitizer. But I didn't hit the problem. Jan Dne Po 18. srpna 2014 18:01:15, Alexander Potapenko napsal(a): > 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
