|
From: Neulinger, N. <nn...@um...> - 2003-04-15 13:21:03
|
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 |
|
From: Neulinger, N. <nn...@um...> - 2003-04-15 13:23:15
|
Yep, changing envir var for stack size default made it very quiet... Thanks for the tip! -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan=20 > Sent: Tuesday, April 15, 2003 8:21 AM > To: 'Jeremy Fitzhardinge' > Cc: val...@li... > Subject: RE: [Valgrind-users] not understanding some valgrind=20 > errors against afs... >=20 >=20 > I believe that LWP (afs's light weight process library)=20 > defaults to a minimum stack size of 192k for linux. >=20 > Although some of the users of that library request smaller -=20 > 8k/16k/24k/etc. I believe the minimum is enforced. >=20 > Here's the warnings I get when testing: >=20 > =3D=3D11883=3D=3D Warning: client switching stacks? %esp: 0xBFFFEB5C=20 > --> 0x41067ABC > =3D=3D11883=3D=3D Warning: client switching stacks? %esp: 0x41067A08=20 > --> 0xBFFFEB90 > =3D=3D11883=3D=3D Warning: client switching stacks? %esp: 0xBFFFEB8C=20 > --> 0x410AC094 > =3D=3D11883=3D=3D Warning: client switching stacks? %esp: 0x410ABE90=20 > --> 0xBFFFEBC0 > =3D=3D11883=3D=3D Warning: client switching stacks? %esp: 0xBFFFE66C=20 > --> 0x410ABEF4 >=20 > Those are fairly large address changes. It looks to me like=20 > it is switching to a temporary stack stored in malloc'd memory. >=20 > In vg_memory, it talks about a VG_PLAUSIBLE_STACK_SIZE of=20 > 8000000 and VG_HUGE_DELTA of VG_P_S_S / 4.=20 >=20 > I wonder if perhaps the issue is that the above stack=20 > switches show up as changes because it's going from the=20 > normal stack to malloc'd mem, but changes between the fake=20 > stacks are not showing up, since they are small switches=20 > within malloced mem.=20 >=20 > -- Nathan >=20 > ------------------------------------------------------------ > Nathan Neulinger EMail: nn...@um... > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 >=20 >=20 > > -----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=20 > maybe having > > > trouble with this, if this is the problem, is there any=20 > 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 >=20 |
|
From: Yogesh B. <ybh...@ya...> - 2003-04-15 17:05:42
|
--- "Neulinger, Nathan" <nn...@um...> wrote: > Yep, changing envir var for stack size default made it very > quiet... > > Thanks for the tip! > > -- Nathan > Which is this env var? I could not find it in the user manual. I suspect the problem that I am having with testbuilder is quite similar. I would like to try this out. Regards, -- Yogesh __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Neulinger, N. <nn...@um...> - 2003-04-15 17:07:43
|
Sorry, AFS_LWP_STACK_SIZE... it's specific to the afs lwp code to change the stack size that it uses internally. I raised it to larger than 1MB, which passes the threshold for memcheck stack switch code. ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Yogesh Bhagwat [mailto:ybh...@ya...]=20 > Sent: Tuesday, April 15, 2003 12:06 PM > To: Neulinger, Nathan > Cc: val...@li... > Subject: RE: [Valgrind-users] not understanding some valgrind=20 > errors against afs... >=20 >=20 >=20 > --- "Neulinger, Nathan" <nn...@um...> wrote: > > Yep, changing envir var for stack size default made it very > > quiet... > >=20 > > Thanks for the tip! > >=20 > > -- Nathan > >=20 >=20 > Which is this env var? I could not find it in the user manual. > I suspect the problem that I am having with testbuilder is quite > similar. I would like to try this out. >=20 > Regards, > -- > Yogesh >=20 > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com >=20 |
|
From: Yogesh B. <ybh...@ya...> - 2003-04-15 17:27:39
|
--- "Neulinger, Nathan" <nn...@um...> wrote: > Sorry, AFS_LWP_STACK_SIZE... it's specific to the afs lwp code to > change > the stack size that it uses internally. I raised it to larger than > 1MB, > which passes the threshold for memcheck stack switch code. > Ah! OK, I tried a similar option for testbuilder (tbvThreadT::setStackSize()) and indeed it made valgrind very very quite. Thanx a lot for the tip. As a side note, it will be great it valgrind had an option to set the stack size being used by the application, so that if user knows the stacksize (128K default in case of testbuilder) she can use the option to inform valgrind. Is there a formal mechanism to submit a feature request? Regards, -- Yogesh __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2003-04-15 20:31:41
|
On Tue, 15 Apr 2003, Yogesh Bhagwat wrote: > Is there a formal mechanism to submit a feature request? No... this list is as good a way as any. Don't use the Sourceforge site though -- we only use SF for CVS, and rarely look at it otherwise. N |
|
From: Neulinger, N. <nn...@um...> - 2003-04-15 17:35:22
|
I think (from what I understand) that the problem is that if you lower the threshold to something like 128K, valgrind will get confused if you allocate a 128K+ object on the stack. If you're certain that no individual object on the stack would be that size, it would probably be useful to have an option to specify it. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Yogesh Bhagwat [mailto:ybh...@ya...]=20 > Sent: Tuesday, April 15, 2003 12:28 PM > To: Neulinger, Nathan > Cc: val...@li... > Subject: RE: [Valgrind-users] not understanding some valgrind=20 > errors against afs... >=20 >=20 >=20 > --- "Neulinger, Nathan" <nn...@um...> wrote: > > Sorry, AFS_LWP_STACK_SIZE... it's specific to the afs lwp code to > > change > > the stack size that it uses internally. I raised it to larger than > > 1MB, > > which passes the threshold for memcheck stack switch code. > >=20 > Ah! OK, I tried a similar option for testbuilder=20 > (tbvThreadT::setStackSize()) and indeed it made valgrind=20 > very very quite. Thanx a lot for the tip. >=20 > As a side note, it will be great it valgrind had an option to > set the stack size being used by the application, so that if > user knows the stacksize (128K default in case of testbuilder) > she can use the option to inform valgrind. >=20 > Is there a formal mechanism to submit a feature request? >=20 > Regards, > -- > Yogesh >=20 >=20 >=20 > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com >=20 |
|
From: Nicholas N. <nj...@ca...> - 2003-04-15 20:30:34
|
On Tue, 15 Apr 2003, Neulinger, Nathan wrote: > I think (from what I understand) that the problem is that if you lower > the threshold to something like 128K, valgrind will get confused if you > allocate a 128K+ object on the stack. If you're certain that no > individual object on the stack would be that size, it would probably be > useful to have an option to specify it. Would a client request be a good compromise? Eg. insert VALGRIND_STACK_SWITCH just before the stack switch? It's more intrusive than a command line option, but it's more precise. Similar to the client request for handling self-modifying code. [I haven't thought through how the request would actually be implemented, but it shouldn't be too hard, I think...] N |
|
From: Robert W. <rj...@du...> - 2003-04-15 20:51:03
|
> Would a client request be a good compromise? Eg. insert > VALGRIND_STACK_SWITCH just before the stack switch? It's more intrusive > than a command line option, but it's more precise. Similar to the client > request for handling self-modifying code. > > [I haven't thought through how the request would actually be implemented, > but it shouldn't be too hard, I think...] JeremyF and I had a chat about this over lunch a few weeks ago. One idea floated was to check what the instruction that was ultimately responsible for the stack switch was. If it was a move to sp type instruction, it's probably a stack switch. Otherwise it's probably a push or a pop. JeremyF did mention a few days ago that he was trying something new but was running into problems - maybe this was what he was trying but it wasn't turning out to be that easy... :-) Regards, Robert. |
|
From: Sebastian K.
|
Hello! Dnia wto 15. kwiecie=F1 2003 22:50, Robert Walsh napisa=B3: > JeremyF and I had a chat about this over lunch a few weeks ago. One > idea floated was to check what the instruction that was ultimately > responsible for the stack switch was. If it was a move to sp type > instruction, it's probably a stack switch. Otherwise it's probably a > push or a pop. JeremyF did mention a few days ago that he was trying > something new but was running into problems - maybe this was what he wa= s > trying but it wasn't turning out to be that easy... :-) How about following approach (rough idea): Checking wether value loaded into ESP fits within some memory block alloc= ated=20 by malloc call (V is keeping track of those blocks anyway). If ESP skips = from=20 one such block into another, this is probably stack switch. Now we only h= ave=20 to remember, that initial stack is not mallocated and handle that=20 apropriately (remembering where initial, primary stack was when EPS skips= out=20 into some mallocated block). This surely wouldn't work for multiple stacks residing in the same malloc= ated=20 block, but then maybe V could use some combined approach (or even user=20 configurable combination of detecting ESP change amount, if it's caused b= y=20 MOV, not ADD/SUB/etc... and the above proposed method, and maybe somethin= g=20 else). Also allowing code instrumentation is not bad idea. Also it might be desi= rable=20 to allow user supply the address of stack switching instruction from comm= and=20 line -- there are probably very few places in the whole code where stack=20 switch itself is actually performed, and this would allow to use library = one=20 has no sources for (or one does not want to recompile). Just rough ideas, but maybe useful... rgds Sebastian Kaliszewski sk@z.pl |
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:33:19
|
Quoting Robert Walsh <rj...@du...>: > JeremyF and I had a chat about this over lunch a few weeks ago. One > idea floated was to check what the instruction that was ultimately > responsible for the stack switch was. If it was a move to sp type > instruction, it's probably a stack switch. Otherwise it's probably a > push or a pop. No, if its a move, its probably a longjmp; you still can't tell whether its a stack switch or a longjmp within the stack. J |
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:31:58
|
Quoting Nicholas Nethercote <nj...@ca...>: > On Tue, 15 Apr 2003, Neulinger, Nathan wrote: > > > I think (from what I understand) that the problem is that if you > lower > > the threshold to something like 128K, valgrind will get confused if > you > > allocate a 128K+ object on the stack. If you're certain that no > > individual object on the stack would be that size, it would probably > be > > useful to have an option to specify it. > > Would a client request be a good compromise? Eg. insert > VALGRIND_STACK_SWITCH just before the stack switch? It's more > intrusive > than a command line option, but it's more precise. Similar to the > client > request for handling self-modifying code. > > [I haven't thought through how the request would actually be > implemented, > but it shouldn't be too hard, I think...] Yeah, it would. It would need to mean something like "the next change to %esp is a stack switch", but what if changing the stack changes %esp multiple times? How do you know if the compiler is going to generate some non-stack switch changes to %esp as part of its codegen? I think the correct solution is to move stack switch detection into the skin themselves (memcheck, addrcheck and helgrind are the only ones I know of which care). Memcheck and addrcheck can use their existing validity info to make the determination; helgrind is harder. J |
|
From: Nicholas N. <nj...@ca...> - 2003-04-17 08:47:04
|
On Thu, 17 Apr 2003, Jeremy Fitzhardinge wrote: > > Would a client request be a good compromise? Eg. insert > > VALGRIND_STACK_SWITCH just before the stack switch? It's more > > intrusive than a command line option, but it's more precise. Similar > > to the client request for handling self-modifying code. > > > > [I haven't thought through how the request would actually be > > implemented, but it shouldn't be too hard, I think...] > > Yeah, it would. It would need to mean something like "the next change to %esp is > a stack switch", but what if changing the stack changes %esp multiple times? How > do you know if the compiler is going to generate some non-stack switch changes to > %esp as part of its codegen? Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, and within that look for a "sizeable" %esp change (eg. anything bigger than 1KB or something) as a genuine switch? Or maybe not, I don't know. > I think the correct solution is to move stack switch detection into the skin > themselves (memcheck, addrcheck and helgrind are the only ones I know of which > care). Memcheck and addrcheck can use their existing validity info to make the > determination; helgrind is harder. How does validity info help? N |
|
From: Sebastian K. <Seb...@so...> - 2003-04-17 10:27:00
|
From: "Nicholas Nethercote" <nj...@ca...> > Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, and > within that look for a "sizeable" %esp change (eg. anything bigger than > 1KB or something) as a genuine switch? Or maybe not, I don't know. Hello! Just some not-insider suggestion: Maybe then use VALGRING_START_STACK_SWITCH(min_size)? min_size would be used to determine if ESP change is sizeable? rgds Sebastian Kaliszewski |
|
From: Jeremy F. <je...@go...> - 2003-04-18 09:29:17
|
Quoting Nicholas Nethercote <nj...@ca...>: > Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, > and > within that look for a "sizeable" %esp change (eg. anything bigger > than > 1KB or something) as a genuine switch? Or maybe not, I don't know. Tricky if the context switch is performed by an instruction which both changes %esp and %eip (ie, leave). There would be no way to place the "after" annotation. > > > I think the correct solution is to move stack switch detection into > the skin > > themselves (memcheck, addrcheck and helgrind are the only ones I know > of which > > care). Memcheck and addrcheck can use their existing validity info to > make the > > determination; helgrind is harder. > > How does validity info help? Basically, if you're extending the stack over some already-valid memory, it means you're switching to a new stack at a lower address (since the valid memory is one or more intermediate stacks, or some other allocated memory); if you're shrinking the stack over some already-invalid memory, you're actually switching to a stack with a higher address. The only case where I can think of this failing is if your current stack has another stack just above it which has grown to touch/overlap this stack, and you context switch to it. But if that has happened, you've already got into deep trouble. Hm, now that I think about it, it doesn't really work that well when the stacks are in heap memory. But then, how well does V cope with that anyway? Wouldn't it allow access below %esp? J |
|
From: Josef W. <Jos...@in...> - 2003-04-17 13:37:43
|
On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote: > ... > I think the correct solution is to move stack switch detection into the > skin themselves (memcheck, addrcheck and helgrind are the only ones I know > of which care). Memcheck and addrcheck can use their existing validity > info to make the determination; helgrind is harder. Calltree does ESP tracking, too. Needed for recursion detection and correct handling of setjmp/longjmp or C++ exceptions and like that. So I'm voting for a skin trackable event for stack switching from the core. Isn't this almost the same as the "switch_thread" event? As I see, the first stack switch always has quite a large delta. If we remember the instruction address somehow and assume further stack switches if the same instruction is executed (breaking up a BB into two at this point). [This is new in the resend to Valgrind-users] Another idea: Doesn't the kernel need to know about stack segments somehow by declaring the VMA as growable? So isn't it enough to check for ESP changes among growable VMAs? Or how behaves the LWP lib of AFS on stack overflows? If it uses mprotect() for manual stack growing, we can track this, too. Josef |
|
From: Jeremy F. <je...@go...> - 2003-04-18 09:40:55
|
Quoting Josef Weidendorfer <Jos...@in...>: > On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote: > > ... > > I think the correct solution is to move stack switch detection into > the > > skin themselves (memcheck, addrcheck and helgrind are the only ones I > know > > of which care). Memcheck and addrcheck can use their existing > validity > > info to make the determination; helgrind is harder. > > Calltree does ESP tracking, too. Needed for recursion detection and > correct > handling of setjmp/longjmp or C++ exceptions and like that. > > So I'm voting for a skin trackable event for stack switching from the > core. > Isn't this almost the same as the "switch_thread" event? > As I see, the first stack switch always has quite a large delta. If we switch_thread is a clear event which the scheduler knows about. A change of value in %esp can mean one of two things, and there's no way of really telling what it means without some heuristics. The heuristics we have at present get it wrong too often, with very bad results. > Doesn't the kernel need to know about stack segments somehow by > declaring the > VMA as growable? So isn't it enough to check for ESP changes among > growable > VMAs? > Or how behaves the LWP lib of AFS on stack overflows? If it uses > mprotect() > for manual stack growing, we can track this, too. The kernel only grows the main stack, not thread stacks; thread stacks are generally never growable. Thinking about it, I quite like Sebastian's idea of a VALGRIND_STACK_SWITCH(thresh) call. This would mean "when you see a %esp movement of at least threah bytes, that's a stack switch". This would be a trigger thing, in that once the motion has been seen, future %esp changes are seen as being within one stack until another call to VALGRIND_STACK_SWITCH. Note that if stacks are closely spaced, thresh would be considerably smaller than the stack size (since going from a full stack adjacent empty stack just below would be an %esp movement of less than a stack size - it could be arbitarily small). J |
|
From: Sebastian K. <Seb...@so...> - 2003-04-18 13:13:11
|
From: "Jeremy Fitzhardinge" <je...@go...> > Thinking about it, I quite like Sebastian's idea of a > VALGRIND_STACK_SWITCH(thresh) call. This would mean "when you see a %esp > movement of at least threah bytes, that's a stack switch". This would be a > trigger thing, in that once the motion has been seen, future %esp changes are > seen as being within one stack until another call to VALGRIND_STACK_SWITCH. > > Note that if stacks are closely spaced, thresh would be considerably smaller than > the stack size (since going from a full stack adjacent empty stack just below > would be an %esp movement of less than a stack size - it could be arbitarily > small). Oh, thats the problem. But then, if we're already at placing hints in the source, then maybe another one: VALGRIND_REGISTER_STACK(adr, size) -- this would inform Valgrind that particular memory area is possibly going to become a separate stack at some time in the future. This would also work as invalidator for stack allocated from heap. To make stuff easier nagative value of size would mean that area is below (not above) adr, which could be sometimes more natural approach work stacks growing downwards. Then add VALGRIND_UNREGISTER_STACK(adr). rgds Sebastian Kaliszewski > > J > > > ------------------------------------------------------- > 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 > |
|
From: Neulinger, N. <nn...@um...> - 2003-04-17 13:43:43
|
> Or how behaves the LWP lib of AFS on stack overflows? If it=20 > uses mprotect()=20 > for manual stack growing, we can track this, too. I'm pretty sure it behaves really badly. The stack switching I believe is fairly limited, and is being used to implement threads. The application is responsible for requesting a large enough stack to handle it's deepest nesting of calls. Since it's a server, and fairly predictable, that isn't usually a problem. -- Nathan |
|
From: Thomas R. T. <tr...@cs...> - 2003-04-17 13:59:35
|
valgrind seems to have a problem with swapcontext() tasking.
We use getcontext/setcontext/swapcontext
rather than setjmp/longjmp for tasking.
The *context routines are slower than *jmp
but seem to be a more official API for tasking.
For example the program below triggers messages such as:
==26015== Invalid write of size 4
==26015== at 0x42045D6C: __swapcontext (in /lib/i686/libc-2.2.93.so)
==26015== Address 0xBFFFE9BC is on thread 1's stack
This isn't a problem for us, since we can optionally use pthread tasking.
But I thought I should mention it.
Tom Truscott
#include <stdio.h>
#include <stdlib.h>
#include <ucontext.h>
ucontext_t child, parent;
#define STACKSZ (256*1024)
void childfunc(void)
{
printf("entering child\n");
swapcontext(&child, &parent);
printf("leaving child\n");
}
int
main()
{
printf("entering main\n");
getcontext(&child);
child.uc_link = 0;
child.uc_stack.ss_sp = malloc(STACKSZ);
child.uc_stack.ss_size = STACKSZ;
child.uc_stack.ss_flags = 0;
makecontext(&child, (void(*)())childfunc, 0);
swapcontext(&parent, &child);
printf("leaving main\n");
return 0;
}
|
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:18:29
|
Quoting "Neulinger, Nathan" <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:
>
> ==11883== Warning: client switching stacks? %esp: 0xBFFFEB5C -->
> 0x41067ABC
> ==11883== Warning: client switching stacks? %esp: 0x41067A08 -->
> 0xBFFFEB90
> ==11883== Warning: client switching stacks? %esp: 0xBFFFEB8C -->
> 0x410AC094
> ==11883== Warning: client switching stacks? %esp: 0x410ABE90 -->
> 0xBFFFEBC0
> ==11883== 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.
>
> 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.
Yup, that would be it. Make HUGE_DELTA smallish and see if that helps (and
increase the LWP stack size if you can).
J
|