Re: [Valgrind-users] memory barriers support

[Jan V. <jan...@ni...>]

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...@ni...> 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