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

[Neulinger, N. <nn...@um...>]

I believe that LWP (afs's light weight process library) defaults to a
minimum stack size of 192k for linux.

Although some of the users of that library request smaller -
8k/16k/24k/etc. I believe the minimum is enforced.

Here's the warnings I get when testing:

=3D=3D11883=3D=3D Warning: client switching stacks?  %esp: 0xBFFFEB5C =
-->
0x41067ABC
=3D=3D11883=3D=3D Warning: client switching stacks?  %esp: 0x41067A08 =
-->
0xBFFFEB90
=3D=3D11883=3D=3D Warning: client switching stacks?  %esp: 0xBFFFEB8C =
-->
0x410AC094
=3D=3D11883=3D=3D Warning: client switching stacks?  %esp: 0x410ABE90 =
-->
0xBFFFEBC0
=3D=3D11883=3D=3D Warning: client switching stacks?  %esp: 0xBFFFE66C =
-->
0x410ABEF4

Those are fairly large address changes. It looks to me like it is
switching to a temporary stack stored in malloc'd memory.

In vg_memory, it talks about a VG_PLAUSIBLE_STACK_SIZE of 8000000 and
VG_HUGE_DELTA of VG_P_S_S / 4.=20

I wonder if perhaps the issue is that the above stack switches show up
as changes because it's going from the normal stack to malloc'd mem, but
changes between the fake stacks are not showing up, since they are small
switches within malloced mem.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:je...@go...]=20
> Sent: Monday, April 14, 2003 6:10 AM
> To: Neulinger, Nathan
> Cc: val...@li...
> Subject: Re: [Valgrind-users] not understanding some valgrind=20
> errors against afs...
>=20
>=20
> Quoting Nathan Neulinger <nn...@um...>:
>=20
> > 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?
>=20
> The big question is how large are the thread stacks, and how=20
> far apart are they
> in memory?  Valgrind's only heuristic for distinguishing=20
> between longjmp within
> a stack vs. longjmp between stacks is looking at the size of=20
> the esp movement;
> if it is large, it is a stack switch, and if small it is=20
> within one stack.
>=20
> This heuristic is horribly broken if you have relatively=20
> small stacks closely
> spaced.  Normally, when %esp moves to a lower address,=20
> Valgrind considers the
> stack to be extended, which means the memory becomes=20
> available for use.=20
> Conversely, when %esp goes up, the memory under %esp is=20
> considered non-valid. =20
>=20
> Now, if Valgrind sees %esp move up, and assumes it is within=20
> one stack, then all
> the memory between the old value and the new value is=20
> invalidated.  If it was,
> in fact, a stack switch, it has probably completely=20
> invalidated one or more of
> your stacks, and therefore their local variables, return=20
> address, etc.  This can
> cause massive numbers of spurious errors (including errors at=20
> the end of a
> function caused by a return to an undefined return address).
>=20
> There is no good workaround for this at the moment, except by=20
> changing the
> heuristic threshhold constant (in vg_memory.c from memory,=20
> but I don't have the
> source with me at the moment).
>=20
> I have a better solution in mind, but the first=20
> implementation didn't work; I
> need to think about it more.
>=20
>     J
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>=20