i386 memory fence incompatible with valgrind

Marc Lehmann schmorp at schmorp.de
Wed Jan 11 09:10:52 CET 2017

On Wed, Jan 11, 2017 at 08:35:38AM +0100, Matthias Urlichs <matthias at urlichs.de> wrote:
> On 11.01.2017 08:14, Marc Lehmann wrote:
> > The area *is* a legitimate memory location, and I am sure valgrind agrees.
> Umm, while it's legitimate to access it, the problem is that it cannot
> have any defined content – an interrupt could alter the data stored
> there at any time.

That's totally fine, the fence doesn't use or modify the contents.

> Valgrind knows that, thus it complains.

Thats a non-sequitur. I know that, but I don't complain. The cpu knows it,
but neither does it complain (it will just work).

This is clearly a problem in valgrind - assuming the message you get is about
use of uninitialised values, then its a bug per documentation:

   An uninitialised-value use error is reported when your program uses a value
   which hasn't been initialised

The fence doesn't use an uninitialised value. The problem here is that
valgrind doesn't properly understand the instruction, and the fix can only
be done by teaching valgrind about the instruction, just as with any other
instruction not understood by valgrind.

In general, valgrind as a tool loses usefulness if it generates spurious
errors or warnings, and there realyl isn't an excuse for valgrind to fix

> > The instruction is a standard memory fence pattern also used by linux
> > for example,
> Linux uses 0(%esp). Why are you using an offset of -1?

The code is taken from linux, so if you see 0, you are probably looking at
a diferent version. In fact, at least linux 4.9 doesn't even use or, but
add, so it seems to change over time.

> An offset of zero would fix the problem.

That's wrong, the problem cannot go away just because libev doesn't emit
the instrzuction anymore. Since the problem is valgrind not understanding
the memory fence, it can only be fixed in valgrind. Changing libev will cause
valgrind's bug to not trigger, but the bug will still remain in valgrind.

It clearly would be better if valgrind were fixed to recognize this
instruction and not generate spurious errors.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list