i386 memory fence incompatible with valgrind

Marc Lehmann schmorp at schmorp.de
Sun Jan 15 15:47:27 CET 2017


On Sat, Jan 14, 2017 at 07:06:44PM +0100, Matthias Urlichs <matthias at urlichs.de> wrote:
> On 14.01.2017 17:52, Marc Lehmann wrote:
> > 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.
> No it would not, because the kernel would notice that the access in
> question, unlike yours is *not* below the stack pointer, because the CPU
> first decrements the stack pointer and then tries to store something
> there. The kernel would therefore just extend the stack downwards. A
> memory checker would do the exact same thing.

Matthias - the only thing you are demonstrating here is your ability to
make up things and your total lack of technical understanding. The kernel
allocates pages depending on the address thats faulting, it will not
disassemble the instruction and see how the address was calculated.

Evidence to the contrary is welcome.

> In any case, I'd assume that the main author of a tool like valgrind
> knows a whole damn lot about this stuff.

After what you wrote, I'd assume so as well, yes. So do I, btw. In any
case, agruments of the form "my dick is longer than yours" are utterly
boring and, I hate to say it again, not at all convincing.

> Bullshit? not so much, IMHO.

Well, opinions are great, but what counts is facts - the instruction
is valid and by yll appearances works. The problem is not that the
instruction somehow fails, the problem is that valgrind doesn't understand
it, and the problem in valgrind has nothing to do with the fact that the
access is below the stack pointer at the time.

> I wanted to call bullshit, which I'm not, I'd start with your assertion
> that the -1 is to be found in the kernel.

Everybody is entitled to mistakes, even me. The difference is that I
instantly acknowledged that my memory was faulty and dropped it, while you
continue to beat a dead horse with ever more bullshit.

Even more so, I didn't use this as an argument on why the code is correct
(that would be a logical fallacy), as you should be able to understand
- even if I am totally wrong about where the code is from, this has
no bearing on its validity, again a difference to the arguments you
mentioned, which directly try and fail to attack the validity of the code.

I hope you can see the difference.

> No, it's not your job to improve valgrind, but it's both your and the
> valgrind author's job to get the two to play nicely with each other.

And why would that be the case? It would help if you stopped pulling more
and more things out of your ass and stayed with facts.

> Given that each of you thinks that the other is mistaken (NB: for what
> it's worth, Julian didn't call "utter bullshit"), it's still a whole lot
> easier to replace a single -1 with zero than to teach valgrind about
> possibly-or-not legal accesses below the stack.

Libev is not about going the easy way and adding layers of hacks upon
hacks to make things "work". None of my code is. If you want code that
adds wahtever hack necessary to make things superficially work, you are
at the wrong place and need to look elsewhere.

In this case it's clearly valgrind that is buggy. If the maintaienr of
valgrind doesn't see that or doesn't care for whatever reason, it's not
my duty, as you wrongly claim, to make my code potentially worse to work
around a bug in valgrind.

Nor is it my duty to communicate with the valgrind mkaintaienr and point
out where he is wrong. I bellieve you when you say you notified him and he
doesn't want to fix it.

In any case, this conversation has long lost any purpose, I said what
I wanted to say, and nothing you came up with is in any way or form
convincing, mostly because it's not based on facts.

There is really nothing to add.

Good luck,

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