i386 memory fence incompatible with valgrind

Marc Lehmann schmorp at schmorp.de
Sat Jan 14 17:52:31 CET 2017


On Thu, Jan 12, 2017 at 10:33:50AM +0100, Matthias Urlichs <matthias at urlichs.de> wrote:
> > Personally, I would do as I suggesxted in my first reply, namly asking
> > them to correctly recognize the memory fence instruction.
> As I thought, the author of valgrind states that what you're doing is
> not OK.

He clearly is wrong, and shockignly so. So shicking that I wonder if he
really looked at the same instruction, because he is so obviously wrong.

> The libev code is incorrect and should be fixed.  It it violates the ABI.

Nothing in the ABI is violated, of course. He probably doesn't understand
what atomicity means, or doesn't understand the x86 lock prefix.

> The problem isn't that the memory is uninitialised.  It is that the
> program isn't allowed to access below %esp at any time, for at least
> the following reasons:
> 
> * a signal may get delivered at any time, in which case the signal
>   handler's frame will overwrite the value at -1(%esp).

Yes, a signal handler could do that and everything would just work of
course.

> * since the kernel "knows" that programs may not access below %esp, it
>   would be within its rights to unmap the page containing -1(%esp).
>   If %esp pointed exactly to the bottom of a page then the access
>   at -1(%esp) would cause an unexpected page (segmentation) fault.

That is, sorry to say, utter bullshit. If the kernel unmaps that page
and returns to the userland, it would crash on the next stack allocation
as well. While the kernel cna always crash programs (and validly so for
example on stack overflow), this case is in no way different than other
non-contested accesses.

> If you think Julian is wrong,

It's clearly that julian has no clue what he is talking about.

I'm shocked that somebody like him has any say with valgrind, he clearlky
should have more competence if he speaks for valgrind.

> please talk to him directly.

Why would I? It's not my job to educate people, and not my job to improve
valgrind. If the valgrind maintainers don't want to fix their bugs, that
is their choice, not mine.

In any case, I guess everythiong has been clared up by now - the code
works fine and is correct on actual x86, and valgrind doesn't want to
emulate x86 correctly. Bad choice, imho, but not mine.

-- 
                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