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: Biswapesh C. <bis...@tc...> - 2003-04-16 08:23:03
|
I just did: calltree ./SciTE ~/GNOME2.2/src/anjuta/src/aneditor.cxx It just creates some 0 byte cachegrind.out.* files :-( No warnings about unable to write this time though. Any clues ? On Wed, 2003-04-16 at 13:38, Nicholas Nethercote wrote: > On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > > > I'm getting the following error with CVS valgrind + cachegrind skin ( > > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > > --logfile-fd=6' > > /opt/gnome2.2/bin/valgrind > > > > ------------------------------------ > > ==6863== error: can't open cache simulation output file > > `cachegrind.out.6863' > > ==6863== ... so simulation results will be missing. > > ------------------------------------ > > > > A 0 byte file cachegrind.out.6863 is created. There is sufficient space > > in the harddisk : > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/hda2 37334192 15213876 20223844 43% / > > Is file descriptor 6 legitimate? Does it work if you let Valgrind's > output go to stderr as usual? > > N -- Biswa. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:23:01
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > The thing is that I compiled valgrind CVS HEAD from source and then I > compiled the latest version of calltree from source, so I'm a mystified > as to why it did not catch this at compile time. Because the latest version of calltree is not quite up-to-date. > The error goes away if I specify the 1_9_5 branch of valgrind during > checkout and then recompile both in that order. Good. N |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 08:19:03
|
The thing is that I compiled valgrind CVS HEAD from source and then I compiled the latest version of calltree from source, so I'm a mystified as to why it did not catch this at compile time. The error goes away if I specify the 1_9_5 branch of valgrind during checkout and then recompile both in that order. On Wed, 2003-04-16 at 13:43, Nicholas Nethercote wrote: > On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > > > ------------------------------------ > > Error: > > Skin and core interface versions do not match. > > Interface version used by core is: 2.0 > > Interface version used by skin is: 1.2 > > The major version numbers must match. > > You need to at least recompile, and possibly update, > > your skin to work with this version of Valgrind. > > Aborting, sorry. > > ------------------------------------- > > > > What gives ? > > Let me guess: you're using the CVS head with the calltree patch. The > core/skin interface changed recently, and now the core you are using > doesn't match the skin any more. If you recompile the skin it will > hopefully work, although depending on how up-to-date your core version is, > it may complain about a missing function when trying to print the command > line usage message. I think Josef F has a fix for Calltree for that. > > I tried to make the error message pretty clear... could I make it more > informative? > > N -- Biswa. |
|
From: Luke H.
|
>No, you can't disable it. The only reason we ship our own is that
>V can't simulate some important things in the real pthread library.
>All in all it's a gain pain in various parts of the body for us to
>have our own pthreads library, and believe me, we wouldn't do so if
>we could run the real one.
Understood. Do you have any suggestions about how I might debug this
RPC server which appears to be unvalgrindable?
Before receiving an RPC, the main thread has the following stack:
(gdb) bt
#0 0x40192fb2 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so
#1 0x4052a3d2 in recvmsg (fd=9, message=0x496e784c, flags=0) at libc_jacket.c:221
#2 0x45fbed05 in RPC_SOCKET_RECVMSG (sock=9, iovp=0x496e7974, iovlen=1, addrp=0x0, ccp=0x496e797c,
serrp=0x496e7970) at ../../../ncklib/include/comsoc_bsd.h:339
#3 0x45fbe791 in receive_packet (assoc=0x417993b8, fragbuf_p=0x496e7ba4, ovf_fragbuf_p=0x496e7ba0,
st=0x496e7b98) at cnrcvr.c:1281
#4 0x45fbcded in receive_dispatch (assoc=0x417993b8) at cnrcvr.c:508
#5 0x45fbc4c6 in rpc__cn_network_receiver (assoc=0x417993b8) at cnrcvr.c:274
#6 0x4053358c in thread_wrapper (info=0x4179950c) at vg_libpthread.c:671
#7 0x4016ce88 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2152
After:
(gdb) bt
#0 vg_do_syscall2 (syscallno=1079222716, arg1=1077504048, arg2=0) at vg_mylibc.c:76
#1 0x00000004 in ?? ()
#2 0x4017f9e2 in vgPlain_main () at vg_main.c:1442
Setting a breakpoint on siglongjmp() crashes valgrind.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:13:29
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > ------------------------------------ > Error: > Skin and core interface versions do not match. > Interface version used by core is: 2.0 > Interface version used by skin is: 1.2 > The major version numbers must match. > You need to at least recompile, and possibly update, > your skin to work with this version of Valgrind. > Aborting, sorry. > ------------------------------------- > > What gives ? Let me guess: you're using the CVS head with the calltree patch. The core/skin interface changed recently, and now the core you are using doesn't match the skin any more. If you recompile the skin it will hopefully work, although depending on how up-to-date your core version is, it may complain about a missing function when trying to print the command line usage message. I think Josef F has a fix for Calltree for that. I tried to make the error message pretty clear... could I make it more informative? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:08:56
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > I'm getting the following error with CVS valgrind + cachegrind skin ( > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > --logfile-fd=6' > /opt/gnome2.2/bin/valgrind > > ------------------------------------ > ==6863== error: can't open cache simulation output file > `cachegrind.out.6863' > ==6863== ... so simulation results will be missing. > ------------------------------------ > > A 0 byte file cachegrind.out.6863 is created. There is sufficient space > in the harddisk : > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda2 37334192 15213876 20223844 43% / Is file descriptor 6 legitimate? Does it work if you let Valgrind's output go to stderr as usual? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:05:47
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > Is there any reason why the calltree skin > (http://kcachegrind.sourceforge.net/) is not included by default with > valgrind ? Seems darn useful to me :-) We had to draw the line somewhere w.r.t the number of skins to include in the default distribution. It's kind of arbitrary. N |
|
From: Julian S. <js...@ac...> - 2003-04-16 07:58:57
|
> All in all it's a gain pain in various parts of the body for us to
^
t
Duh.
J
|
|
From: Julian S. <js...@ac...> - 2003-04-16 07:54:27
|
No, you can't disable it. The only reason we ship our own is that V can't simulate some important things in the real pthread library. All in all it's a gain pain in various parts of the body for us to have our own pthreads library, and believe me, we wouldn't do so if we could run the real one. J On Wednesday 16 April 2003 8:32 am, Luke Howard wrote: > I'm trying to debug a problem with a DCE RPC server, which uses exception > handling implemented on top of pthread cancels and > sigsetjmp()/siglongjmp(). > > This appears to cause problems with valgrind after the first client > request: > > ==29326== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup > handlers are ignored) > > After which the call stack is trashed and the server is catatonic. In > attempting to find the bug I'm looking for, I'm wondering whether it > is possible to disable valgrind's interposing pthread library. > > -- Luke |
|
From: Luke H.
|
I'm trying to debug a problem with a DCE RPC server, which uses exception handling implemented on top of pthread cancels and sigsetjmp()/siglongjmp(). This appears to cause problems with valgrind after the first client request: ==29326== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored) After which the call stack is trashed and the server is catatonic. In attempting to find the bug I'm looking for, I'm wondering whether it is possible to disable valgrind's interposing pthread library. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:55:48
|
gives: ------------------------------------ Error: Skin and core interface versions do not match. Interface version used by core is: 2.0 Interface version used by skin is: 1.2 The major version numbers must match. You need to at least recompile, and possibly update, your skin to work with this version of Valgrind. Aborting, sorry. ------------------------------------- What gives ? -- Biswa. |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:23:30
|
Hi
I'm getting the following error with CVS valgrind + cachegrind skin (
alias cachegrind='valgrind --skin=cachegrind --num-callers=25
--logfile-fd=6'
/opt/gnome2.2/bin/valgrind
------------------------------------
==6863== error: can't open cache simulation output file
`cachegrind.out.6863'
==6863== ... so simulation results will be missing.
------------------------------------
A 0 byte file cachegrind.out.6863 is created. There is sufficient space
in the harddisk :
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 37334192 15213876 20223844 43% /
Can someone give me a clue ?
Thanks in adavnce.
--
Biswa.
|
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:15:10
|
Hi Is there any reason why the calltree skin (http://kcachegrind.sourceforge.net/) is not included by default with valgrind ? Seems darn useful to me :-) Thanks in advance, and regards, -- Biswa. |
|
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 |