i386 memory fence incompatible with valgrind

Marc Lehmann schmorp at schmorp.de
Wed Jan 11 23:10:46 CET 2017

On Wed, Jan 11, 2017 at 06:01:10PM +0100, Matthias Urlichs <matthias at urlichs.de> wrote:
> On 11.01.2017 09:10, Marc Lehmann wrote:
> > The fence doesn't use an uninitialised value.
> ? It accesses -1(%sp), which is not initialized / undefined / whatever;
> it then processes that value (by ORing it into a register). The fact
> that the result is then thrown away is immaterial

It doesn't throw away the result, but it also doesn't use the
uninitialised value for anything.

> valgrind's rule is that anything that's not a copy triggers the report.

Well, the documentation I quoted disagrees with that, so either this rule
is mentioned elsewhere, and therefore at least the docs are wrong, or it
isn't valgrinds rule, in which case its a code bug. Either way, it's up to
valgrind to improve their program.

Since the documentation I quoted is in line with the intent of valgrind
(finding real problems rather than being a useless tool with spurious
false positives), I lean towards fixing valgrinds code to make it a better

> So even if I can convince the valgrind people to ignore the

Personally, I would do as I suggesxted in my first reply, namly asking
them to correctly recognize the memory fence instruction. I am not sure
why you would want them to ignore the memory access, that seems weird.

> below-the-stack access itself (which is an error in every other case you
> might think of)

I can think of other cases where it isn't an error, so this statement is
not true.

> the checker would immediately raise another error
> because that value is used.

That's just something you made up, and obviously not true. If valgrind
recognized the memory fence correctly, it would of course not raise any
error (and the value still isn't used :).

> I seriously doubt that they'll implement another special case for
> handling this – when an inconsequential change from -1 to zero in your
> code would work just as well.

Do you have *any* data to substantiate that claim? I think not, so this is
another unsubstantiated claim.

Making up stuff and throwing it around as if it were true will not
convince me of changing things to the worse. Try it with less bullshitting
and more fact, and we have can have a reasonable argument.

> > The code is taken from linux, so if you see 0, you are probably looking
> > at a diferent version.
> You may remember that you (or somebody) took that code from Linux, but
> that memory is faulty. I checked.

I trust your check then - I am seriously puzzled, though, and will have to
question the validity of this memory in detail.

                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