valgrind-users — General discussion list for Valgrind users

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

Re: [Valgrind-users] Strange behaviour with both 1.9.x and 1.0.x

[Sebastian <sc...@nb...>]

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! -----------------'

Re: [Valgrind-users] Strange behaviour with both 1.9.x and 1.0.x

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

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

[Valgrind-users] Address ... is on thread 1's stack

[Yogesh B. <ybh...@ya...>]

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

Re: [Valgrind-users] newbie question for a change ;)

[Nicholas N. <nj...@ca...>]

On Mon, 14 Apr 2003, Mathieu Malaterre wrote:

> 	1. I would like to know where the 'KLUDGED call' happens in my soft, is
> it possible to trace it or print the call tree ?

Does your code call pthread_cond_destroy anywhere?

These options may be useful:

    --trace-sched=no|yes      show thread scheduler details? [no]
    --trace-pthread=none|some|all  show pthread event details? [no]


> 	2. Is the python garbage collector well supported in valgrind ?

In theory, any program should work ok, so it should...


> 	3. AS I am having troubles (well just guessing fow now) with threads on
> my SMP linux box does anyone know how to force the soft to only use
> *one* thread (either from c/c++ or python...)?

I don't know about that one.

N

Re: [Valgrind-users] Strange behaviour with both 1.9.x and 1.0.x

[Sebastian <sc...@nb...>]

Hello again,


Just wanted to say that I just tested it with 1.9.5 and that produces
exactly the same behaviour.


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! -----------------'

[Valgrind-users] Strange behaviour with both 1.9.x and 1.0.x

[Sebastian <sc...@nb...>]

Hello,


  I use valgrind a lot and its a really decent program. Today I stumbled
across a quite weird thing which might be a bug in my program, in valgrind
or in both.

This is how both valgrind 1.0.4 (debian unstable) and 1.9.4 (selfcompiled)
complains about code in my program. The first complaint is:

==1682== Use of uninitialised value of size 8
==1682==    at 0x804AB95: be_random_prob (utility.c:111)
==1682==    by 0x804F7CB: codegen_getreg (codegen.c:165)


Where the interesting part of this function is this:

0x804ab7e <be_random_prob+69>:  push   $0xffffffff
0x804ab80 <be_random_prob+71>:  call   0x804aa89 <be_random>
0x804ab85 <be_random_prob+76>:  add    $0x10,%esp
0x804ab88 <be_random_prob+79>:  mov    %eax,0xffffffec(%ebp)
0x804ab8b <be_random_prob+82>:  mov    0xffffffec(%ebp),%eax
0x804ab8e <be_random_prob+85>:  mov    $0x0,%edx
0x804ab93 <be_random_prob+90>:  push   %edx
0x804ab94 <be_random_prob+91>:  push   %eax
0x804ab95 <be_random_prob+92>:  fildll (%esp,1)
0x804ab98 <be_random_prob+95>:  lea    0x8(%esp,1),%esp
0x804ab9c <be_random_prob+99>:  fstpl  0xfffffff0(%ebp)


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). The code was generated by gcc 3.2.3
without any optimizations active.

I attached a test program to this mail, which does _not_ reproduce the bug,
but contains exactly the same code (which I believe to be correct).

So, could the valgrind complaint be a side effect of an uncatched bug
in my program earlier or is it possibly a bug in valgrind? (I can provide
the original program triggering the bug as binary to the authors if they
wish so, but not to the list).


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! -----------------'

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

[Valgrind-users] Example code showing valgrind "hanging" in poll()

[<da...@2g...>]

Hello,

Now I have made a small example that has the following properties:

1) The server works standalone

2) The server works in valgrind 1.0.4

3) The server does not work in valgrind 1.9.5

My system is RedHat Linux 8 with the latest updates. Output from `uname -a`:

Linux zion.2good.net 2.4.18-27.8.0 #1 Fri Mar 14 06:45:49 EST 2003 i686 i686
i386 GNU/Linux

Some RPM versions:

  glib-1.2.10-8
  glib-devel-1.2.10-8

  glibc-2.3.2-4.80.6
  glibc-devel-2.3.2-4.80.6

Download my example code here:

  http://www.2good.nu/tmp/server.tar.gz

Just type make to build. Start the server in one shell and run the client in
another shell.

Expected output from server:

connect now!                     <-- when the server starts
client found? condition=1        <-- when a client connects
New client! (6)
In thread
Socket closed                    <-- this never happens in valgrind 1.9.5

The client does not provide any output, it should just connect and then exit
when the server closes the connection.

Thank you very much,

David Eriksson

Re: [Valgrind-users] newbie question for a change ;)

[Mathieu M. <Mat...@cr...>]

Nicholas,
	Thanks for replying, anyway I still have some questions.
	1. I would like to know where the 'KLUDGED call' happens in my soft, is 
it possible to trace it or print the call tree ?

	2. Is the python garbage collector well supported in valgrind ?

	3. AS I am having troubles (well just guessing fow now) with threads on 
my SMP linux box does anyone know how to force the soft to only use 
*one* thread (either from c/c++ or python...)?

thanks,
mathieu

Nicholas Nethercote wrote:
> On Fri, 11 Apr 2003, Mathieu Malaterre wrote:
> 
> 
>>1. What does : "valgrind's libpthread.so: KLUDGED call to:
>>pthread_cond_destroy" means ?
>>
>>I wasn't able to translate KLUDGED ...
> 
> 
> 'kludged' means something like 'faked' or 'handled semi-bogusly'.  I'm not
> sure exactly what it means in this context, but some parts of V's
> libpthread.so aren't really complete.  It may not matter for your program,
> I think.
> 
> 
>>2. And what does
>>
>>" Syscall param writev(vector[...]) contains uninitialised or
>>unaddressable byte(s)
>>at 0x40237951: my_do_syscall3 (vg_libpthread.c:2389)
>>by 0x40236BA8: vgIntercept_writev (vg_libpthread.c:2055)
>>by 0x4017BF68: __writev (vg_intercept.c:287)
>>by 0x43246B45: (within /usr/X11R6/lib/libX11.so.6.2)
>>Address 0x413C7FD8 is 124 bytes inside a block of size 2048 alloc'd
>>at 0x40165F4D: calloc (vg_clientfuncs.c:242)
>>by 0x4321D6FE: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
>>by 0x430BEB12: gdk_init_check (in /usr/lib/libgdk-1.2.so.0.9.1)
>>by 0x42EC3CA1: gtk_init_check (in /usr/lib/libgtk-1.2.so.0.9.1)"
>>
>>means ?
> 
> 
> Some code within libX11.so.2 is calling the sys call writev() with some
> bogus memory -- in this case, it looks like some of the memory block
> passed to writev() (via a pointer) is uninitialised.  The 2nd half of the
> error tells you where the block in question was allocated.
> 
> If it's in libX11.so, that might be out of your control? in which case you
> could suppress it if it does not affect your program, but it sounds like
> it unfortunately does in this case.
> 
> N
> 
> 
> 


-- 
Mathieu Malaterre
CREATIS
28 Avenue du Doyen LEPINE
B.P. Lyon-Montchat
69394 Lyon Cedex 03
http://www.creatis.insa-lyon.fr/~malaterre/

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

[Nathan N. <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?

First, what is the problem here:

==26290== Invalid write of size 4
==26290==    at 0x8097889: rxi_AllocPacketNoLock
(/umr/s/openafs/openafs/src/rx/rx_packet.c:637)
==26290==    by 0x8097927: rxi_AllocSendPacket
(/umr/s/openafs/openafs/src/rx/rx_packet.c:674)
==26290==    by 0x809B463: rxi_WriteProc
(/umr/s/openafs/openafs/src/rx/rx_rdwr.c:731)
==26290==    by 0x809B963: rx_WriteProc32
(/umr/s/openafs/openafs/src/rx/rx_rdwr.c:909)
==26290==    Address 0x4106C444 is 16552 bytes inside a block of size
80752 alloc'd
==26290==    at 0x40166741: malloc (vg_clientfuncs.c:103)
==26290==    by 0x80972F2: rxi_MorePackets
(/umr/s/openafs/openafs/src/rx/rx_packet.c:366)
==26290==    by 0x808BA70: rx_Init
(/umr/s/openafs/openafs/src/rx/rx.c:458)
==26290==    by 0x806A7A1: vsu_ClientInit
(/umr/s/openafs/openafs/src/volser/vsutils.c:425)


Why is the read invalid if it's a 4 byte read 16552 bytes inside a block
of size 80752? 

Second, how can this code:


afs_int32 savecontext(ep, savearea, sp)
char    (*ep)();
struct lwp_context *savearea;
char*   sp;
{
        int code;

        PRE_Block = 1;
        EP = ep;

        code =  setjmp(savearea->setjmp_buffer);
        jmpBuffer = (jmp_buf_type *)savearea->setjmp_buffer;
        savearea->topstack = (char*)jmpBuffer[LWP_SP];

#if     defined(DEBUG)
        {
            int i, *ptr = (int*)savearea->setjmp_buffer;
            printf("savecontext\n");
            for ( i=0; i < 5; i++)
                printf("(%d) 0x%x   ",i, ptr[i]);
            printf("\n");
            for ( i=5; i < 10; i++)
                printf("(%d) 0x%x   ",i, ptr[i]);
            printf("\n");
        }
#endif
        switch ( code )
        {
                case 0: if ( !sp )
                        (*EP)();
                        else


generate a unitialized error on the "switch ( code )" line? That doesn't
seem to be possible unless the setjmp is returning an unitialized value
as it's result.

-- Nathan

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

Re: [Valgrind-users] newbie question for a change ;)

[Nicholas N. <nj...@ca...>]

On Fri, 11 Apr 2003, Mathieu Malaterre wrote:

> 1. What does : "valgrind's libpthread.so: KLUDGED call to:
> pthread_cond_destroy" means ?
>
> I wasn't able to translate KLUDGED ...

'kludged' means something like 'faked' or 'handled semi-bogusly'.  I'm not
sure exactly what it means in this context, but some parts of V's
libpthread.so aren't really complete.  It may not matter for your program,
I think.

> 2. And what does
>
> " Syscall param writev(vector[...]) contains uninitialised or
> unaddressable byte(s)
> at 0x40237951: my_do_syscall3 (vg_libpthread.c:2389)
> by 0x40236BA8: vgIntercept_writev (vg_libpthread.c:2055)
> by 0x4017BF68: __writev (vg_intercept.c:287)
> by 0x43246B45: (within /usr/X11R6/lib/libX11.so.6.2)
> Address 0x413C7FD8 is 124 bytes inside a block of size 2048 alloc'd
> at 0x40165F4D: calloc (vg_clientfuncs.c:242)
> by 0x4321D6FE: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
> by 0x430BEB12: gdk_init_check (in /usr/lib/libgdk-1.2.so.0.9.1)
> by 0x42EC3CA1: gtk_init_check (in /usr/lib/libgtk-1.2.so.0.9.1)"
>
> means ?

Some code within libX11.so.2 is calling the sys call writev() with some
bogus memory -- in this case, it looks like some of the memory block
passed to writev() (via a pointer) is uninitialised.  The 2nd half of the
error tells you where the block in question was allocated.

If it's in libX11.so, that might be out of your control? in which case you
could suppress it if it does not affect your program, but it sounds like
it unfortunately does in this case.

N

[Valgrind-users] What a great program.

[Chuck S. <su...@so...>]

Valgrind developers (especially Julian Seward and Nick Nethercote),

Valgrind just saved my bacon yet again by finding an obscure memory
problem in some 100,000 lines of source. Thanks for creating such a
robust, easy to use, well documented program. Truly amazing.

Thanks again,
-Chuck Sugnet

Re: [Valgrind-users] periodical flush of cachegrind.out

[Josef W. <Jos...@gm...>]

On Friday 11 April 2003 22:15, Charlls Quarra wrote:
>  Hi,
>
>  Im wondering if its possible to cachegrind to
> periodically dump a partial cachegrind.out file, so
> one can check the profile statistics without finishing
> the application

Hi Charlls,

take a look at my call-tree skin (I think I should rename it to callgraph, 
shouldn't I?) at kcachegrind.sf.net. The newest version 0.2.93 allows for

1) ad hoc dumping ("touch cachegrind.cmd" while running). This method is 
"supported" with auto-reloading after the dump in KCachegrind by clicking on 
a toolbar button.

2) periodic dumping every <count> basic blocks (--dumps=<count>).

3) dumping at enter/leave of all functions whose name starts with <funcprefix> 
(--dump-before=<funcprefix>/--dump-after=<funcprefix>). I choose the prefix 
method so with C++ you don't have to specify full signatures. You can specify 
this option multiple times.

4) program controlled dumping: "#include <valgrind/calltree.h>" into your 
source and add "CALLTREE_DUMP_STATS;" when you want a dump to happen.

If you are running a multi-threaded application and specify 
"--dump-threads=yes", every thread will be profiled on its own and will 
create its own profile dump. Thus, (3) and (4) will only generate one dump of 
the currently running thread. With (1) and (2), you will get multiple dumps 
(one for each thread) on a dump request. 

The generated dump files get names

	cachegrind.out.<pid>[.<part>][-<threadID>]

where <pid> is the PID of the running program, <part> is a number incremented 
on each dump (".<part>" is skipped for the dump at program termination), 
<threadID> is a thread identification.
When your program changes the current working directory while running, the 
dump files will get spread out into different directory. This can be avoided 
by specifying a dump file base name with an absolute path with 
"--base=/tmp/cachegrind.out".

You can control for which part of your program you want to collect event costs 
by using --toggle-collect=<funcprefix>. This will toggle the collection state 
on entering and leaving a function. When specifying this option, the default 
collecting state at programm start is "off". Thus, only events happing while 
running inside of <funcprefix> will be collected. Recursive function calls of 
<funcprefix> don't influence collecting at all.

Note that cache simulation still will be done all the time to be usefull. 
Thus, you don't have any speedup while collection state is off. But you can 
switch off cache simulation with "--simulate-cache=no". This will only give 
instruction read accesses and the callgraph tracing. But it significantly 
speeds up the profiling typically by more than a factor of 2.

There is an option to ignore calls to a function with 
"--fn-skip=<funcprefix>". E.g. you usually don't want to see the trampoline 
functions in the PLT sections for calls to functions in shared libs. You can 
see the difference if you profile with "--skip-plt=no". If a call is ignored, 
cost events happening will be attached to the enclosing function.

The remaining options are used to avoid cycles in profile data.
* if you have a recursive function, you can distinguish the first 10 recursion 
levels by specifying "--fn-recursion10=<funcprefix>". Or for all functions 
with "fn-recursion=10", but this will give you *much* bigger profile dumps.
In the profile data, you will see the recursion levels of "func" as the 
different functions with names "func", "func'2", "func'3" and so on.
* if you have call chains "A > B > C" and "A > C > B" in your program, you 
usually get a "false" cycle "B <> C". Use "--fn-caller2=B --fn-caller2=C", 
and functions "B" and "C" will be treated as different functions depending on 
the direct caller. Using the apostrophe for appending this "context" to the 
function name, you get "A > B'A > C'B" and "A > C'A > B'C", and there will be 
no cycle. Use "--fn-callers=3" to get a 2-caller depencendy for *all* 
functions. Again, this will multiplicate the profile data size.

Cheers,
Josef

Re: [Valgrind-users] periodical flush of cachegrind.out

[Julian S. <js...@ac...>]

I think Josef Weidendorfer's kcachegrind patches might be able to
do this, or something like it.  See here:

http://kcachegrind.sourceforge.net/

J

On Friday 11 April 2003 8:15 pm, Charlls Quarra wrote:
>  Hi,
>
>  Im wondering if its possible to cachegrind to
> periodically dump a partial cachegrind.out file, so
> one can check the profile statistics without finishing
> the application
>
>
>  Greetings
>
>
> ------------
> ¡Internet GRATIS es Yahoo! Conexión!
> Usuario "yahoo", contraseña "yahoo".
> Desde Buenos Aires, 4004-1010.
> Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] periodical flush of cachegrind.out

[<cha...@ya...>]

 

 Hi,

 Im wondering if its possible to cachegrind to
periodically dump a partial cachegrind.out file, so
one can check the profile statistics without finishing
the application


 Greetings


------------
¡Internet GRATIS es Yahoo! Conexión!
Usuario "yahoo", contraseña "yahoo". 
Desde Buenos Aires, 4004-1010.
Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html

[Valgrind-users] newbie question for a change ;)

[Mathieu M. <Mat...@cr...>]

Hi all,
	Once again I'll start by saying that I am a newbie and please bear with 
me...blabla

	Ok now I introduced myself ;) I have two questions:

1. What does : "valgrind's libpthread.so: KLUDGED call to: 
pthread_cond_destroy" means ?

I wasn't able to translate KLUDGED ...

2. And what does

" Syscall param writev(vector[...]) contains uninitialised or 
unaddressable byte(s)
at 0x40237951: my_do_syscall3 (vg_libpthread.c:2389)
by 0x40236BA8: vgIntercept_writev (vg_libpthread.c:2055)
by 0x4017BF68: __writev (vg_intercept.c:287)
by 0x43246B45: (within /usr/X11R6/lib/libX11.so.6.2)
Address 0x413C7FD8 is 124 bytes inside a block of size 2048 alloc'd
at 0x40165F4D: calloc (vg_clientfuncs.c:242)
by 0x4321D6FE: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
by 0x430BEB12: gdk_init_check (in /usr/lib/libgdk-1.2.so.0.9.1)
by 0x42EC3CA1: gtk_init_check (in /usr/lib/libgtk-1.2.so.0.9.1)"

means ? Please note that this message isn't shown if I start my app with 
option '--sync', which mean that X whill be started in synchronize mode 
: XSynchronize(display,True). If this sole message doesn't give any clue 
on what the problem is, could someone told me what to do then (use gtk 
debug lib, X debug lib -if such beast exists-, ...)


I was running valgrind on my linux box with lastest nvidia driver with 
the following command line:

  __GL_FORCE_GENERIC_CPU=1 valgrind -v --leak-check=yes python2.2 wxMyApp.py

thanks,
mathieu
Ps: I am trying to debug an app that works perfectly if using '--sync' 
option but freeze my X session if started without '--sync' option.

-- 
Mathieu Malaterre
CREATIS
28 Avenue du Doyen LEPINE
B.P. Lyon-Montchat
69394 Lyon Cedex 03
http://www.creatis.insa-lyon.fr/~malaterre/

[Valgrind-users] [PATCH] SIOCOUTQ ioctl support for valgrind 1.9.5

[Lennert B. <bu...@gn...>]

(Please CC on replies, I'm not on the list.)

SIOCOUTQ is an ioctl that, when called on a socket, returns the number
of bytes currently in that socket's send buffer.  It writes this value
as an int to the memory location indicated by the third argument of
ioctl(2).

Below is a trvial patch that implements support for this ioctl, and
corrects some text in README_MISSING_SYSCALL_OR_IOCTL.



diff -urN valgrind-1.9.5-orig/README_MISSING_SYSCALL_OR_IOCTL valgrind-1.9.5/README_MISSING_SYSCALL_OR_IOCTL
--- valgrind-1.9.5-orig/README_MISSING_SYSCALL_OR_IOCTL	Fri Mar 22 02:29:21 2002
+++ valgrind-1.9.5/README_MISSING_SYSCALL_OR_IOCTL	Fri Apr 11 16:10:39 2003
@@ -12,7 +12,7 @@
 there's not a lot of need to distinguish them (at least conceptually)
 in the discussion that follows.
 
-All this machinery is in vg_syscall_mem.c.
+All this machinery is in coregrind/vg_syscalls.c.
 
 
 What are syscall/ioctl wrappers?  What do they do?
@@ -141,12 +141,6 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Is pretty much the same as writing syscall wrappers.
 
-If you can't be bothered, do a cheap hack: add it (the ioctl number
-emitted in Valgrind's panic-message) to the long list of IOCTLs which
-are noted but not fully handled by Valgrind (search for the text
-"noted but unhandled ioctl" in vg_syscall_mem.c).  This will get you
-going immediately, at the risk of giving you spurious value errors.
-
 As above, please do send me the resulting patch.
 
 
diff -urN valgrind-1.9.5-orig/coregrind/vg_syscalls.c valgrind-1.9.5/coregrind/vg_syscalls.c
--- valgrind-1.9.5-orig/coregrind/vg_syscalls.c	Fri Apr  4 00:44:27 2003
+++ valgrind-1.9.5/coregrind/vg_syscalls.c	Fri Apr 11 16:13:41 2003
@@ -2010,7 +2010,7 @@
                                             arg3, sizeof(int) );
                KERNEL_DO_SYSCALL(tid,res);
                break;
-            case FIONREAD:
+            case FIONREAD:		/* identical to SIOCINQ */
                SYSCALL_TRACK( pre_mem_write, tst, "ioctl(FIONREAD)", 
                                              arg3, sizeof(int) );
                KERNEL_DO_SYSCALL(tid,res);
@@ -2152,6 +2152,13 @@
                if (!VG_(is_kerror)(res) && res == 0)
                   VG_TRACK( post_mem_write,arg3, sizeof(struct timeval));
                break;
+            case SIOCOUTQ:
+               SYSCALL_TRACK( pre_mem_write,tst, "ioctl(SIOCOUTQ)", arg3, 
+                                sizeof(int));
+               KERNEL_DO_SYSCALL(tid,res);
+               if (!VG_(is_kerror)(res) && res == 0)
+                  VG_TRACK( post_mem_write,arg3, sizeof(int));
+               break;
             case SIOCGRARP:           /* get RARP table entry         */
             case SIOCGARP:            /* get ARP table entry          */
                SYSCALL_TRACK( pre_mem_write,tst, "ioctl(SIOCGARP)", arg3, 
diff -urN valgrind-1.9.5-orig/coregrind/vg_unsafe.h valgrind-1.9.5/coregrind/vg_unsafe.h
--- valgrind-1.9.5-orig/coregrind/vg_unsafe.h	Sat Oct  5 17:18:27 2002
+++ valgrind-1.9.5/coregrind/vg_unsafe.h	Fri Apr 11 16:13:58 2003
@@ -41,6 +41,7 @@
 #include <sys/resource.h> /* for struct rlimit */
 #include <linux/shm.h>    /* for struct shmid_ds & struct ipc_perm */
 #include <sys/socket.h>   /* for struct msghdr */
+#include <linux/sockios.h> /* for SIOCOUTQ */
 #include <sys/un.h>       /* for sockaddr_un */
 #include <net/if.h>       /* for struct ifreq et al */
 #include <net/if_arp.h>   /* for struct arpreq */

Re: [Valgrind-users] Dump to a file

[Nicholas N. <nj...@ca...>]

On Thu, 10 Apr 2003, Xiang Yan wrote:

> I know 1.9.5 has an option of dumping message to a file, but 1.0.4
> online help doesn't have this info. Any way can dump valgrind's output
> to a file for v1.0.4

Not quite, but there is this option:

    --logfile-fd=<number>     file descriptor for messages [2=stderr]

N

Re: [Valgrind-users] Using valgrind on a system with nvidia

[Julian S. <js...@ac...>]

The non-working of valgrind with nvidia drivers might go away when
we finally get around to implementing SSE/SSE2 instructions, which 
we hope will happen soon.  

However, NVidia also noticed this it seems, and the "latest" drivers
(don't ask me what version, I don't use them) come with this text

        DISABLING CPU SPECIFIC FEATURES

        Setting the environment variable __GL_FORCE_GENERIC_CPU to a
        non-zero value will inhibit the use of CPU specific features
        such as MMX, SSE, or 3DNOW!.  Use of this option may result in
        performance loss.  This option may be useful in conjunction with
        software such as the Valgrind memory debugger.

__GL_FORCE_GENERIC_CPU=1 valgrind ... whatever ...

apparently does work.  Great stuff.  Ah yes, version 4349 according
to Sylvain's just-arrived message.

J


On Friday 11 April 2003 5:36 am, Paul Cheyrou-lagreze wrote:
> I use both on the same linux system :
>
> 1. install latest nvidia driver
> 2. download Mesa source from mesa3d.org
> 3. compile and install Mesa from sources (make install should install it in
> /usr/local/lib/) (if you're coding some opengl try configure --enable-warn
> --enable-trace, you'll get some VERY useful information)
>
> Then, when you want to use Mesa,
> just launch a shell command
> export LD_LIBRARY_PATH=/usr/local/lib
> and launch apps. (Valgrind included)
>
> When you want to use hardware opengl,
> export LD_LIBRARY_PATH=
>
> Then you can test code with both, and debug with Mesa, wich is easier.
>
> -Paul
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Using valgrind on a system with nvidia

[Sylvain J. <syl...@m4...>]

You can disable the use of MMX/SSE/whatever in the latest nvidia driver=20
(4349) by setting the __GL_FORCE_GENERIC_CPU environment variable to a=20
non-zero value

=46rom the readme:

DISABLING CPU SPECIFIC FEATURES

Setting the environment variable __GL_FORCE_GENERIC_CPU to a non-zero
value will inhibit the use of CPU specific features such as MMX, SSE,
or 3DNOW!.  Use of this option may result in performance loss.  This
option may be useful in conjunction with software such as the Valgrind
memory debugger.
=2D-=20
Sylvain Joyeux

Re: [Valgrind-users] Using valgrind on a system with nvidia

[Paul Cheyrou-l. <Pau...@in...>]

I use both on the same linux system :

1. install latest nvidia driver
2. download Mesa source from mesa3d.org
3. compile and install Mesa from sources (make install should install it in /usr/local/lib/)
(if you're coding some opengl try configure --enable-warn --enable-trace, 
you'll get some VERY useful information)

Then, when you want to use Mesa, 
just launch a shell command 
export LD_LIBRARY_PATH=/usr/local/lib
and launch apps. (Valgrind included)

When you want to use hardware opengl,
export LD_LIBRARY_PATH=

Then you can test code with both, and debug with Mesa, wich is easier.

-Paul

[Valgrind-users] Using valgrind on a system with nvidia

[Paul H. <pa...@ha...>]

My company bought a new Linux system so I can run valgrind faster.  The
purchasing department doesn't understand Linux, so it came with Windows XP
installed and a high end Nvidia graphics card.  Getting rid of Windows XP
was easy, but I think I'm stuck with the Nvidia card.  The "nv" driver
mostly works, but text was getting messed up when xterms scrolled.  So I
tried the drivers from Nvidia.  Now my xterms worked, but valgrind stopped
working.

As many are painfully aware, the problem isn't the hardware, it is the
drivers.  Specifically it's /usr/lib/libGL.so.1.0.4349 and libraries it
pulls in.

My system is mostly Debian unstable.  After foolishly installing the
Nvidia drivers, I got valgrind to work again by typing:

  apt-get install --reinstall xlibmesa3-gl

This puts back the /usr/X11R6/lib/libGL.so.1.2 that the Nvidia install
script removed.  The nvidia stuff is libGL.so.1.0 and the mesa3-gl is
 .1.2, so I can probably play with version numbers to get either library.
The mesa library is fast enough for me, since I spend far more time
working on the CAD program than I do actually running the CAD program with
large models. Most importantly, my xterms don't get messed up when I
scroll them.

I've tried valgrind 1.0.4, 1.9.5 and the CVS tip (why does it call itself
1.9.4?), and they all work on this somewhat bastardized OpenGL
configuration.

Performance with the Mesa libGL and the "nvidia" driver is much better
than it was with the "nv" driver.  (That might just mean I screwed up the
"nv" driver configuration.)

I spent some time playing with LD_LIBRARY_PATH to get different libraries,
this worked, but it looked like I'd have to spend time maintaining
multiple suppression files, since our older Linux systems aren't cursed
with the Nvidia hardware.

--
Paul Haas, pa...@Ha...

RE: [Valgrind-users] Unable to build valgrind on RedHat Linux 7.2

[Conrad H. <CH...@fo...>]

 Thank you so much; it built and installed perfectly just now with a locally
built Make 3.80. This version of RedHat Linux used Make 3.79. Problem
solved!

-----Original Message-----
From: Julian Seward
To: Conrad Heiney; 'val...@li...'
Cc: Sean Crowe
Sent: 4/10/03 2:26 PM
Subject: Re: [Valgrind-users] Unable to build valgrind on RedHat Linux 7.2


> make: expand.c:489: allocated_variable_append: Assertion
> `current_variable_set_list->next != 0' failed.

Yeh, I've seen this before a couple of times.  Somehow it seems
like a bug in GNU make.  All I can suggest is that you try a 
newer version of gnu make (I guess it is not hard to build
from source).

J


>
> Is there a workaround for this, or should I stay with 1.0.4 or some
other
> earlier version on this version of Linux?
>
> Thanks,
>
> Conrad Heiney
> Senior Unix System Administrator
> FOXSports.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The
debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost
and
> disoriented. TotalView can help you find your way. Available on major
UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Unable to build valgrind on RedHat Linux 7.2

[Julian S. <js...@ac...>]

> make: expand.c:489: allocated_variable_append: Assertion
> `current_variable_set_list->next != 0' failed.

Yeh, I've seen this before a couple of times.  Somehow it seems
like a bug in GNU make.  All I can suggest is that you try a 
newer version of gnu make (I guess it is not hard to build
from source).

J


>
> Is there a workaround for this, or should I stay with 1.0.4 or some other
> earlier version on this version of Linux?
>
> Thanks,
>
> Conrad Heiney
> Senior Unix System Administrator
> FOXSports.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users