Re: [Valgrind-users] not understanding some valgrind errors against afs...

[Jeremy F. <je...@go...>]

Quoting Nathan Neulinger <nn...@um...>:

> First off, openafs is doing some user-space threading using
> setjmp/etc.
> There seems to be a mention in the valgrind docs about maybe having
> trouble with this, if this is the problem, is there any workaround?

The big question is how large are the thread stacks, and how far apart are they
in memory?  Valgrind's only heuristic for distinguishing between longjmp within
a stack vs. longjmp between stacks is looking at the size of the esp movement;
if it is large, it is a stack switch, and if small it is within one stack.

This heuristic is horribly broken if you have relatively small stacks closely
spaced.  Normally, when %esp moves to a lower address, Valgrind considers the
stack to be extended, which means the memory becomes available for use. 
Conversely, when %esp goes up, the memory under %esp is considered non-valid.  

Now, if Valgrind sees %esp move up, and assumes it is within one stack, then all
the memory between the old value and the new value is invalidated.  If it was,
in fact, a stack switch, it has probably completely invalidated one or more of
your stacks, and therefore their local variables, return address, etc.  This can
cause massive numbers of spurious errors (including errors at the end of a
function caused by a return to an undefined return address).

There is no good workaround for this at the moment, except by changing the
heuristic threshhold constant (in vg_memory.c from memory, but I don't have the
source with me at the moment).

I have a better solution in mind, but the first implementation didn't work; I
need to think about it more.

    J