You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
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: 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: 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: 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: Maarten B. <maa...@mi...> - 2003-04-15 19:26:04
|
Hi,
It might be stating the obvious ... but it is always a GoodIdea(tm)
to check the return values of system calls.
Cheers,
Maarten.
On Tue, 2003-04-15 at 16:41, Philippe Elie wrote:
> Sebastian wrote:
> > Hi,
> >
>
> > unsigned int
> > be_random (unsigned int max)
> > {
> > unsigned int tmp;
> >
> >
> > if (rand_fd == -1)
> > be_randinit ();
> >
> > read (rand_fd, &tmp, sizeof (tmp));
> >
> > /* 0 denotes special 0 to 2^32 - 1 range
> > */
> > if (max == 0)
> > return (tmp);
> >
> > return (tmp % max);
> > }
>
>
> > In any case, there is no way for be_random to return without defining
> %eax.
>
> if read fails tmp is not initialized
>
> regards,
> Philippe Elie
--
Maarten Ballintijn <maa...@mi...>
Massachusetts Institute of Technology
|
|
From: Philippe E. <ph...@wa...> - 2003-04-15 18:36:41
|
Sebastian wrote:
> Hi,
>
> unsigned int
> be_random (unsigned int max)
> {
> unsigned int tmp;
>
>
> if (rand_fd == -1)
> be_randinit ();
>
> read (rand_fd, &tmp, sizeof (tmp));
>
> /* 0 denotes special 0 to 2^32 - 1 range
> */
> if (max == 0)
> return (tmp);
>
> return (tmp % max);
> }
> In any case, there is no way for be_random to return without defining
%eax.
if read fails tmp is not initialized
regards,
Philippe Elie
|
|
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: 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: 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: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: Nicholas N. <nj...@ca...> - 2003-04-15 14:25:55
|
On Mon, 14 Apr 2003, Yogesh Bhagwat wrote:
> I get numerous errors like:
> Address 0x43096454 is on thread 1's stack
>
> This error occurs at a line that looks like:
>
> if (tvm.rst == 1) {
>
> tvm is a reference to an object that was created on heap in the main
> testbuilder thread. rst is a data member of tvm.
>
> So I could not quite figure out the meaning of this messege.
> Any help understanding this error msg is greatly appreciated.
Well, 'tvm' itself may be on the stack; you could add a
debugging-printf() at that point to confirm this. I don't know if this
will make things any clearer, though.
N
|
|
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: 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: Sebastian <sc...@nb...> - 2003-04-15 07:08:56
|
Hi,
On Mon, Apr 14, 2003 at 06:16:18PM -0700, Jeremy Fitzhardinge wrote:
> Well, the behaviour you're seeing is consistent with be_random() returning
> an undefined value in %eax. FP instructions like fildll immediately check
> the defined-ness of their values (unlike integer instructions, which only
> check for defined-ness when the value is used as a pointer or in a
> conditional instruction). It may be that be_random() has a bug, or it is
> returning an undefined value as a result of an undefined input.
unsigned int
be_random (unsigned int max)
{
unsigned int tmp;
if (rand_fd == -1)
be_randinit ();
read (rand_fd, &tmp, sizeof (tmp));
/* 0 denotes special 0 to 2^32 - 1 range
*/
if (max == 0)
return (tmp);
return (tmp % max);
}
This code looks correct to me. 'rand_fd' leads to /dev/urandom, so to
valgrind it should just look like if 'tmp' is defined by the read(), and the
return value defined by the modulo operation.
0x804aa89 <be_random>: push %ebp
0x804aa8a <be_random+1>: mov %esp,%ebp
0x804aa8c <be_random+3>: sub $0x8,%esp
0x804aa8f <be_random+6>: cmpl $0xffffffff,0x8065668
0x804aa96 <be_random+13>: jne 0x804aa9d <be_random+20>
0x804aa98 <be_random+15>: call 0x804aa4e <be_randinit>
0x804aa9d <be_random+20>: sub $0x4,%esp
0x804aaa0 <be_random+23>: push $0x4
0x804aaa2 <be_random+25>: lea 0xfffffffc(%ebp),%eax
0x804aaa5 <be_random+28>: push %eax
0x804aaa6 <be_random+29>: pushl 0x8065668
0x804aaac <be_random+35>: call 0x8048a28 <read>
0x804aab1 <be_random+40>: add $0x10,%esp
0x804aab4 <be_random+43>: cmpl $0x0,0x8(%ebp)
0x804aab8 <be_random+47>: jne 0x804aac2 <be_random+57>
0x804aaba <be_random+49>: mov 0xfffffffc(%ebp),%eax
0x804aabd <be_random+52>: mov %eax,0xfffffff8(%ebp)
0x804aac0 <be_random+55>: jmp 0x804aad0 <be_random+71>
0x804aac2 <be_random+57>: mov 0xfffffffc(%ebp),%eax
0x804aac5 <be_random+60>: mov $0x0,%edx
0x804aaca <be_random+65>: divl 0x8(%ebp)
0x804aacd <be_random+68>: mov %edx,0xfffffff8(%ebp)
0x804aad0 <be_random+71>: mov 0xfffffff8(%ebp),%eax
0x804aad3 <be_random+74>: leave
0x804aad4 <be_random+75>: ret
(Unoptimized GCC 3.2.3 code).
In any case, there is no way for be_random to return without defining %eax.
> J
ciao,
Sebastian
--
-. sc...@nb... -. + http://segfault.net/~scut/ `--------------------.
-' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07
`- 4 BLU-82/MOAB articles offered, payment due. hi echelon! -----------------'
|
|
From: Jeremy F. <je...@go...> - 2003-04-15 01:16:36
|
Quoting Sebastian <sc...@nb...>:
> It extracted all functions taking part in this code to extra files and
> ran
> some tests, without successes. The situation is quite simple:
> be_random
> returns one random unsigned int (in %eax), %edx is zeroed out, a 64
> bit
> integer is temporarily created on the stack and the resulting number
> is
> loaded into a double register (fildll).
Well, the behaviour you're seeing is consistent with be_random() returning an
undefined value in %eax. FP instructions like fildll immediately check the
defined-ness of their values (unlike integer instructions, which only check for
defined-ness when the value is used as a pointer or in a conditional
instruction). It may be that be_random() has a bug, or it is returning an
undefined value as a result of an undefined input.
There doesn't seem to be anything wrong with this particular piece of code, or
with Valgrind's behaviour.
J
|
|
From: Yogesh B. <ybh...@ya...> - 2003-04-15 00:35:03
|
Hello, I am using valgrind for a code that uses testbuilder (www.testbuilder.net). Testbuilder is verification C++ class library that uses quickthreads to provide concurrency. I get numerous errors like: Address 0x43096454 is on thread 1's stack This error occurs at a line that looks like: if (tvm.rst == 1) { tvm is a reference to an object that was created on heap in the main testbuilder thread. rst is a data member of tvm. So I could not quite figure out the meaning of this messege. Any help understanding this error msg is greatly appreciated. Thanks, -- Yogesh PS. I thank the creators of valgrind for an excellent tool. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com |