valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Debugging a DCE RPC server

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

On Thursday 10 April 2003 10:21 am, David Eriksson wrote:
> On Thu, 2003-04-10 at 12:14, Luke Howard wrote:
> > >What valgrind version are you using?
> >
> > 1.9.3. I will try 1.9.5 and report any improvements.
>
> May I suggeest that you also try the old 1.0.4 version.
>
> The reason for this is that I have a program with sockets and threads
> that works fine in 1.0.4 but has problems in 1.9.4. I haven't tried
> 1.9.5 yet.

Really?  Can you send a test case?  That shouldn't happen.  I know 
there are some difficulties on glibc-2.3.X systems, but apart from
that 1.9.X should run anything 1.0.X runs.

J

Re: [Valgrind-users] Definitely lost

[Crispin F. <cr...@th...>]

I just tried the sample code (once I had got it to compile) and it
worked fine - as expected. If you can provide a complete program that
acts as a test case, then you may have more luck tracking down the
problem in your code.

Crispin

On Thu, 2003-04-10 at 21:28, Xiang Yan wrote:
>  On Thu, 10 Apr 2003, Xiang Yan wrote:
> >
> > > My question is, for code below, valgrind will report an error or not on
> memory allocated for c1::m_p1?
> > > class c1
> > > {
> > >    ~c1()
> > >  {
> > >    delete []m_p1;
> > >  }
> > >  void * m_p1;
> > > }
> > >
> > > class c2
> > > {
> > >  ~c2() {
> > >    if(m_c1 != NULL)
> > >       delete []m_c1;
> > >  }
> > >  func1() {
> > >    m_c1 = new c1[10];
> > >    for(i = 0; i < 10; i++) {
> > >      m_c1[i].m_p1 = new char[10]; // reports definitely lost here
> > >   }
> > >  }
> > >   c1 *m_c1;
> > > }
> > >
> > > somewhere else outside above class has following call:
> > > c2 *pc2 = new c2();
> > > c2->func1();
> > > delete c2;
> >
> > You've written an almost-whole program, and you want to know what Valgrind
> > says about it?
> >
> > It looks to me like there won't be any errors, because AFAICT the memory
> > is all deallocated correctly.  But I suggest you finish and compile the
> > program, and run Valgrind on it.
> 
> That's the result of running Valgrind on my code, the line it indicated is
> below with definitly lost message:
> m_c1[i].m_p1 = new char[10];  // refer to above
> (it's multithreaded btw)
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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] Dump to a file

[Xiang Y. <xy...@pr...>]

Hello,

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

TIA


Xiang

Re: [Valgrind-users] Definitely lost

[Xiang Y. <xy...@pr...>]

 On Thu, 10 Apr 2003, Xiang Yan wrote:
>
> > My question is, for code below, valgrind will report an error or not on
memory allocated for c1::m_p1?
> > class c1
> > {
> >    ~c1()
> >  {
> >    delete []m_p1;
> >  }
> >  void * m_p1;
> > }
> >
> > class c2
> > {
> >  ~c2() {
> >    if(m_c1 != NULL)
> >       delete []m_c1;
> >  }
> >  func1() {
> >    m_c1 = new c1[10];
> >    for(i = 0; i < 10; i++) {
> >      m_c1[i].m_p1 = new char[10]; // reports definitely lost here
> >   }
> >  }
> >   c1 *m_c1;
> > }
> >
> > somewhere else outside above class has following call:
> > c2 *pc2 = new c2();
> > c2->func1();
> > delete c2;
>
> You've written an almost-whole program, and you want to know what Valgrind
> says about it?
>
> It looks to me like there won't be any errors, because AFAICT the memory
> is all deallocated correctly.  But I suggest you finish and compile the
> program, and run Valgrind on it.

That's the result of running Valgrind on my code, the line it indicated is
below with definitly lost message:
m_c1[i].m_p1 = new char[10];  // refer to above
(it's multithreaded btw)

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

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

I attempted to upgrade from version 1.0.4 to version 1.9.5 on a Red Hat
Linux 7.2 system, and got the following error on 'make':

make[3]: Entering directory `/home/cheiney/valgrind-1.9.5/coregrind'
source='vg_clientfuncs.c' object='vg_clientfuncs.o' libtool=no \
depfile='.deps/vg_clientfuncs.Po' tmpdepfile='.deps/vg_clientfuncs.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include
-DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O
-fomit-frame-pointer -mpreferred-stack-boundary=2 -g -fno-omit-frame-pointer
-c `test -f 'vg_clientfuncs.c' || echo './'`vg_clientfuncs.c
make: expand.c:489: allocated_variable_append: Assertion
`current_variable_set_list->next != 0' failed.

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

Re: [Valgrind-users] Definitely lost

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

On Thu, 10 Apr 2003, Xiang Yan wrote:

> My question is, for code below, valgrind will report an error or not on memory allocated for c1::m_p1?
> class c1
> {
>    ~c1()
>  {
>    delete []m_p1;
>  }
>  void * m_p1;
> }
>
> class c2
> {
>  ~c2() {
>    if(m_c1 != NULL)
>       delete []m_c1;
>  }
>  func1() {
>    m_c1 = new c1[10];
>    for(i = 0; i < 10; i++) {
>      m_c1[i].m_p1 = new char[10];
>   }
>  }
>   c1 *m_c1;
> }
>
> somewhere else outside above class has following call:
> c2 *pc2 = new c2();
> c2->func1();
> delete c2;

You've written an almost-whole program, and you want to know what Valgrind
says about it?

It looks to me like there won't be any errors, because AFAICT the memory
is all deallocated correctly.  But I suggest you finish and compile the
program, and run Valgrind on it.

N

[Valgrind-users] Definitely lost

[Xiang Y. <xy...@pr...>]

Hello,

I got following message with --leak-check=3Dyes, valgrind 1.0.4.

=3D=3D1750=3D=3D 1825 bytes in 146 blocks are definitely lost in loss =
record 98 o
=3D=3D1750=3D=3D    at 0x400485EC: __builtin_vec_new =
(vg_clientfuncs.c:156)
=3D=3D1750=3D=3D    by 0x8061119: idgapis::prepareparams(void) =
(idgapis.cpp:904)
=3D=3D1750=3D=3D    by 0x806199E: idgapis::proc(void) (idgapis.cpp:1052)
=3D=3D1750=3D=3D    by 0x8063ED7: idgsockthread::callapi(void) =
(idgsockthread.cpp

My question is, for code below, valgrind will report an error or not on =
memory allocated for c1::m_p1?
class c1
{
   ~c1()=20
 {
   delete []m_p1;
 }
 void * m_p1;
}

class c2
{
 ~c2() {
   if(m_c1 !=3D NULL)
      delete []m_c1;
 }
 func1() {
   m_c1 =3D new c1[10];
   for(i =3D 0; i < 10; i++) {
     m_c1[i].m_p1 =3D new char[10];
  }
 }=20
  c1 *m_c1;
}

somewhere else outside above class has following call:
c2 *pc2 =3D new c2();
c2->func1();
delete c2;

TIA

Xiang

Re: [Valgrind-users] A somewhat valgrind-newbie question

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

On 10 Apr 2003, Tom Roeder wrote:

> 	I have a question to which I hope the answer is simple, but I haven't
> managed to find any way to do it short of hacking the code myself.  I
> have a program (it happens to be ns, the network simulator) that I have
> been working on for a while.  There's a memory leak, and it ends up
> getting a signal and dying on an out of memory error.  The problem is
> that when it dies, valgrind gives up too!  I would much rather have
> valgrind catch that signal and print out what it knows about the memory
> problems already.  Similarly, it has occasionally happened that I have
> wanted to stop valgrind short in a run and tell it to print out what it
> knows.  Unfortunately, at least when I did it, Ctrl-C just causes it to
> quit and not tell me anything.  All of this could be solved if there
> were some sort of command-line option like
>
> "--catch-signal-and-report=<signals>"
>
> where I could give it a list of signals and it would report on memory
> problems before giving up when receiving them.  I have a good knowledge
> of C and C++, but I don't have much time to try to understand the
> valgrind code and figure it out and add this option in a way that
> doesn't interfere with other valgrind signal functionality.  If this has
> already been implemented, so much the better.  If not, could anyone give
> me a pointer into where this might be done in the code, so I can try to
> add the signal handlers myself?

Can you catch the signal with the client program?  If so, in the signal
handler, you could call the VALGRIND_DO_LEAK_CHECK macro (just #include
memcheck.h) to do a leak check at that point.

N

[Valgrind-users] A somewhat valgrind-newbie question

[Tom R. <tmr...@cs...>]

Hi valgrind users,

	I have a question to which I hope the answer is simple, but I haven't
managed to find any way to do it short of hacking the code myself.  I
have a program (it happens to be ns, the network simulator) that I have
been working on for a while.  There's a memory leak, and it ends up
getting a signal and dying on an out of memory error.  The problem is
that when it dies, valgrind gives up too!  I would much rather have
valgrind catch that signal and print out what it knows about the memory
problems already.  Similarly, it has occasionally happened that I have
wanted to stop valgrind short in a run and tell it to print out what it
knows.  Unfortunately, at least when I did it, Ctrl-C just causes it to
quit and not tell me anything.  All of this could be solved if there
were some sort of command-line option like

"--catch-signal-and-report=<signals>"

where I could give it a list of signals and it would report on memory
problems before giving up when receiving them.  I have a good knowledge
of C and C++, but I don't have much time to try to understand the
valgrind code and figure it out and add this option in a way that
doesn't interfere with other valgrind signal functionality.  If this has
already been implemented, so much the better.  If not, could anyone give
me a pointer into where this might be done in the code, so I can try to
add the signal handlers myself?

    Thanks muchly, :-)

		Tom Roeder

Re: [Valgrind-users] Clues on cleaning uninitialised value

[Xiang Y. <xy...@pr...>]

> On Thu, 10 Apr 2003, Xiang Yan wrote:
>
> > > > ==32225== Conditional jump or move depends on uninitialised value(s)
> > > > ==32225==    at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv)
> > > > ==32225==    by 0x8684660: CMP_ModularReduce (in
> > /home/xiang/test/m27/srv)
> > > > ==32225==    by 0x868DBA7: Alg_ComputeModQ_GHash (in
> > /home/xiang/test/m27/srv)
> > > > ==32225==    by 0x86686CA: A_X931RandomGenerateBytes (in
> > /home/xiang/test/m27/srv)
> > >
> > > For a start, recompile the code in question with -g if you can, so you
at
> > > least get line numbers in your error messages.
> > >
> >
> > I'm using -g, no line number. I'm suspecting it's inside oracle oci lib.
Is
> > it possible?
>
> Er... is what possible?  Getting line numbers -- depends if you can
> recompile /home/xiang/test/m27/srv, whatever that is...
>
Thanks.
No, it's in debuging mode, couldn't get the line numbers somehow.  All
errors(total 2500) come from one oracle oci function call, so I have to give
up cleaning them :(

Re: [Valgrind-users] Clues on cleaning uninitialised value

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

On Thu, 10 Apr 2003, Xiang Yan wrote:

> > > ==32225== Conditional jump or move depends on uninitialised value(s)
> > > ==32225==    at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv)
> > > ==32225==    by 0x8684660: CMP_ModularReduce (in
> /home/xiang/test/m27/srv)
> > > ==32225==    by 0x868DBA7: Alg_ComputeModQ_GHash (in
> /home/xiang/test/m27/srv)
> > > ==32225==    by 0x86686CA: A_X931RandomGenerateBytes (in
> /home/xiang/test/m27/srv)
> >
> > For a start, recompile the code in question with -g if you can, so you at
> > least get line numbers in your error messages.
> >
>
> I'm using -g, no line number. I'm suspecting it's inside oracle oci lib. Is
> it possible?

Er... is what possible?  Getting line numbers -- depends if you can
recompile /home/xiang/test/m27/srv, whatever that is...

N

Re: [Valgrind-users] Clues on cleaning uninitialised value

[Xiang Y. <xy...@pr...>]

> > I'm developing a server runing on linux, my environment is redhat ads,
> > gcc 2.96. Here are some results from valgrind 1.04, all functions
> > displayed are not mine:). How can I get more clues on cleaning?
> >
> > /// Valgrind 1.0.4
> > ==32225== Conditional jump or move depends on uninitialised value(s)
> > ==32225==    at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv)
> > ==32225==    by 0x8684660: CMP_ModularReduce (in
/home/xiang/test/m27/srv)
> > ==32225==    by 0x868DBA7: Alg_ComputeModQ_GHash (in
/home/xiang/test/m27/srv)
> > ==32225==    by 0x86686CA: A_X931RandomGenerateBytes (in
/home/xiang/test/m27/srv)
>
> For a start, recompile the code in question with -g if you can, so you at
> least get line numbers in your error messages.
>


I'm using -g, no line number. I'm suspecting it's inside oracle oci lib. Is
it possible?

Re: [Valgrind-users] Scheduler problem

[Sebastian K. <Seb...@so...>]

At first (this is my first post here), hello to everyone, especially
developers -- thanks for creating such great tool (it puts some commercial
$$$ stuff, I was once using, to shame -- V is more powerful, more feature
rich, and on text console is much more useable, than the other $tuff was
with gui)

----- Original Message -----
From: "Jeremy Fitzhardinge" <je...@go...>
> Quoting Julian Seward <js...@ac...>:
>
> > Try the patch called 09-rdtsc-calibration from
> > http://www.goop.org/~jeremy/valgrind/
>
> I doubt that will help much - that just stops an assertion failure when
getting
> the calibration.  The basic problem is that the TSC is variable-rate, and
> therefore useless as a timebase.

Well, using TSC for counting time is not *The Right Thing(tm)*. Is it
impossible to use some other measurement instead (at best OS provided)? What
are the issues?

rgds
Sebastian Kaliszewski

Re: [Valgrind-users] Clues on cleaning uninitialised value

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

On Thu, 10 Apr 2003, Xiang Yan wrote:

> I'm developing a server runing on linux, my environment is redhat ads,
> gcc 2.96. Here are some results from valgrind 1.04, all functions
> displayed are not mine:). How can I get more clues on cleaning?
>
> /// Valgrind 1.0.4
> ==32225== Conditional jump or move depends on uninitialised value(s)
> ==32225==    at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv)
> ==32225==    by 0x8684660: CMP_ModularReduce (in /home/xiang/test/m27/srv)
> ==32225==    by 0x868DBA7: Alg_ComputeModQ_GHash (in /home/xiang/test/m27/srv)
> ==32225==    by 0x86686CA: A_X931RandomGenerateBytes (in /home/xiang/test/m27/srv)

For a start, recompile the code in question with -g if you can, so you at
least get line numbers in your error messages.

N

[Valgrind-users] Clues on cleaning uninitialised value

[Xiang Y. <xy...@pr...>]

Hello,

I'm developing a server runing on linux, my environment is redhat ads, =
gcc 2.96. Here are some results from valgrind 1.04, all functions =
displayed are not mine:). How can I get more clues on cleaning?

TIA =20

Xiang=20

/// Valgrind 1.0.4
=3D=3D32225=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D32225=3D=3D    at 0x86823C2: CMP_Compare (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x8684660: CMP_ModularReduce (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x868DBA7: Alg_ComputeModQ_GHash (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x86686CA: A_X931RandomGenerateBytes (in =
/home/xiang/test/m27/srv)

=3D=3D32225=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D32225=3D=3D    at 0x86823D0: CMP_Compare (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x8684660: CMP_ModularReduce (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x868DBA7: Alg_ComputeModQ_GHash (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x86686CA: A_X931RandomGenerateBytes (in =
/home/xiang/test/m27/srv)

=3D=3D32225=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D32225=3D=3D    at 0x86827E8: CMP_CMPIntToOctetString (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x8682944: CMP_CMPIntToFixedLenOctetStr (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x866858E: A_X931RandomGenerateBytes (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x84B6CE4: ztcrandom (in =
/home/xiang/test/m27/srv)

=3D=3D32225=3D=3D Use of uninitialised value of size 4
=3D=3D32225=3D=3D    at 0x84B8931: ztvopepad (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x84B8811: ztvope (in /home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x826A43E: kzsrepw (in /home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x82613F5: kpu8lgn (in /home/xiang/test/m27/srv)

Use of uninitialised value of size 4
=3D=3D32225=3D=3D    at 0x84B3CD7: ztcedecb (in =
/home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x84B8504: ztvo3de (in /home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x84B8832: ztvope (in /home/xiang/test/m27/srv)
=3D=3D32225=3D=3D    by 0x826A43E: kzsrepw (in /home/xiang/test/m27/srv)
=3D=3D32225=3D=3D

Re: [Valgrind-users] Debugging a DCE RPC server

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

On Thu, 10 Apr 2003, Bastien Chevreux wrote:

> Uh, just thinking about it: debugging valgrind with itself, is that possible?
> :-)

Nope, unfortunately not, due to the LD_PRELOAD (ab)use at start-up.  One
of the reasons we'd like to not use it.

Reminds me of an error message I saw on some kind of emulator program
(User Mode Linux, or Wine, or something like that, I can't remember):

  "Error:  Foo cannot run itself.  You just had to try, didn't you?"

N

Re: [Valgrind-users] Debugging a DCE RPC server

[Bastien C. <ba...@ch...>]

On Thursday 10 April 2003 12:31, Luke Howard wrote:
> ...
> And that this is potentially the problem.

Uh, just thinking about it: debugging valgrind with itself, is that possi=
ble?=20
:-)

Salut,
       Bastien

--=20
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --

Re: [Valgrind-users] Debugging a DCE RPC server

[Luke H. <lu...@PA...>]

>The reason for this is that I have a program with sockets and threads
>that works fine in 1.0.4 but has problems in 1.9.4. I haven't tried
>1.9.5 yet.

No luck with 1.9.5 or 1.0.4 I'm afraid. It does appear that the stack
gets smashed (see below) when siglongjmp()/sigsetjmp() are called:

(gdb) bt
#0  vg_do_syscall2 (syscallno=1074473960, arg1=1073822720, arg2=0) at vg_mylibc.c:76
#1  0x00000004 in ?? ()
#2  0x40064136 in vgPlain_main () at vg_main.c:1173
(gdb) 

And that this is potentially the problem.

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com

Re: [Valgrind-users] Debugging a DCE RPC server

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

On Thu, 2003-04-10 at 12:14, Luke Howard wrote:
> >What valgrind version are you using?
> 
> 1.9.3. I will try 1.9.5 and report any improvements.

May I suggeest that you also try the old 1.0.4 version. 

The reason for this is that I have a program with sockets and threads
that works fine in 1.0.4 but has problems in 1.9.4. I haven't tried
1.9.5 yet.

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds

Re: [Valgrind-users] Debugging a DCE RPC server

[Luke H. <lu...@PA...>]

>What valgrind version are you using?

1.9.3. I will try 1.9.5 and report any improvements.

-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com

Re: [Valgrind-users] Debugging a DCE RPC server

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

On Thu, 2003-04-10 at 11:56, Luke Howard wrote:
> I'm attempting to run valgrind on a DCE RPC server. The problem is
> that, while under valgrind, the server doesn't seem to receive any
> client requests. It does work normally, of course, but there are
> a couple of bugs for which valgrind will be very useful in fixing.

What valgrind version are you using?

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds

[Valgrind-users] Debugging a DCE RPC server

[Luke H. <lu...@PA...>]

I'm attempting to run valgrind on a DCE RPC server. The problem is
that, while under valgrind, the server doesn't seem to receive any
client requests. It does work normally, of course, but there are
a couple of bugs for which valgrind will be very useful in fixing.

There are some interesting aspects of the DCE RPC runtime that,
while not necessarily related to this problem, may give valgrind
some grief. The RPC library does the following "weird" things: 

  o wraps the pthread API to provide POSIX Threads Draft
    4 API semantics (however, the symbols do not conflict
    with LinuxThreads)

  o wraps common system calls with jackets that enable
    asynchronous thread cancellation for the duration of
    the system call

  o implements exception handling on top of setjmp()/longjmp()
    and pthread cancels (see below):

/*
 * Note that the rough schema for the exception handler is:
 *
 *      do {
 *          pthread_cleanup_push("routine that will longjmp back here");
 *          val = setjmp(...);  
 *          if (val == 0)
 *              ...normal code...
 *          else
 *              ...exception code...
 *          ...finally code...
 *          if ("exception happened")
 *              if ("exception handled")
 *                  break;
 *              else
 *                  ...re-raise exception...
 *          pthread_cleanup_pop(...);
 *      } while (0);
 * 
 * Exceptions are raised by doing a pthread_cancel against one's self  
 * and then doing a pthread_testcancel.  This causes the topmost cleanup
 * routine to be popped and called.  This routine (_exc_cleanup_handler)
 * longjmp's back to the exception handler.  This approach means we can
 * leverage off the fact that the push/pop routines are maintaining some
 * per-thread state (hopefully [but likely not] more efficiently than
 * we could ourselves).  We need this state to string together the dynamic
 * stack of exception handlers.
 */

Disabling the system call jackets didn't seem to help.

A backtrace of the under-valgrind server follows:

(gdb) bt
#0  0x401924a2 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so
#1  0x4052a1e2 in recvmsg (fd=9, message=0x496ca89c, flags=0) at libc_jacket.c:221
#2  0x45fd1078 in receive_packet (assoc=0x4179608c, fragbuf_p=0x496ca9e4, ovf_fragbuf_p=0x496ca9e8, 
    st=0x496ca9f0) at ../../../ncklib/include/comsoc_bsd.h:339
#3  0x45fcf9ea in receive_dispatch (assoc=0x4179608c) at cnrcvr.c:508
#4  0x45fcf248 in rpc__cn_network_receiver (assoc=0x4179608c) at cnrcvr.c:274
#5  0x4053254c in thread_wrapper (info=0x417961e0) at vg_libpthread.c:667
#6  0x4016c778 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2122

Then, probably after the siglongjmp() call:

(gdb) bt
#0  vg_do_syscall2 (syscallno=1079218620, arg1=1077504048, arg2=0) at vg_mylibc.c:76
#1  0x00000004 in ?? ()
#2  0x4017eff2 in vgPlain_main () at vg_main.c:1384
(gdb) 

Valgrind shows:

04/10 09:56:09 [RPC] Registered endpoint ncacn_ip_tcp:127.0.0.1[1035]
04/10 09:56:09 [RPC] Registered endpoint ncadg_ip_udp:127.0.0.1[1035]
...
==3670== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored)

Any ideas?

cheers,

-- Luke


--
Luke Howard | PADL Software Pty Ltd | www.padl.com

Re: [Valgrind-users] "Reachable" memory, where's the bug (g++, STL, valgrind)?

[Geoff A. <gal...@nc...>]

This appears to be the same libstdc++ "memory leak" I mentioned in the =
"still reachable" memory from g++'s std::string thread, which I started =
on 31 March 2003.  You can check the Valgrind-users archive at =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D1908802&forum_id=
=3D32038.  Note that the thread continues into April, so you'll need to =
search both the March and April archives.  In one of my later postings, =
I give suppression files for suppressing these libstdc++ "still =
reachable" messages for both gcc 2.95.2 and 3.2.
Note that this is working as intended. There are a number of discussions =
on this in the libstdc++ mailing list. For example, see =
http://gcc.gnu.org/ml/libstdc++/2002-10/msg00038.html, =
http://gcc.gnu.org/ml/libstdc++/2002-08/msg00105.html, and =
http://gcc.gnu.org/ml/libstdc++/2002-10/msg00044.html. It's not =
considered a bug, but rather part of a memory cache optimization. From =
http://gcc.gnu.org/ml/libstdc++/2002-08/msg00105.html:

  Both libstdc++-v2 and libstdc++-v3 cache memory internally to greatly =
aid performance yet, as far as we know, no pointers are ever lost as in =
foo().
I believe there are compile options for disabling the libstdc++ memory =
cache optimization if you don't like the behavior.  But if you do, =
expect significant performance degradation on some platforms.

Geoff Alexander

----- Original Message -----=20
From: "Bastien Chevreux" <ba...@ch...>
To: "valgrind users" <val...@li...>
Sent: Wednesday, April 09, 2003 9:45 AM
Subject: [Valgrind-users] "Reachable" memory, where's the bug (g++, STL, =
valgrind)?


Hello there,

I have serious troubles with possible memory leaks in programs heavily
using the STL. I am not able to tell whether it is a problem with the
compiler, the STL or wrong valgrind output, so I'll start here before
filing in a gcc bug report.

One of my programs grew larger and larger without I knew why, so took
valgrind to look and started building testcases to find out what was
happening. I have a SuSE 8.1 distribution, that's kernel 2.4.x,
glibc2.2 and gcc version 3.2

Consider this test case example:

-------------------------------------------------------
#include <vector>
#include <ext/hash_map>
using namespace __gnu_cxx;

void f1()
{
  int n=3D42;
  vector<int> v;
  for(int i=3D0; i<1000000; i++) v.push_back(n);
}

int main(){
  f1();
  return 0;
}
----------------------------------------------------------

g++ -g -o test test.C=20

and then=20

valgrind --leak-resolution=3Dhigh --num-callers=3D20 =
--show-reachable=3Dyes --leak-check=3Dyes ./test

I will get the following summary:

----------------------------------------------------------
=3D=3D16880=3D=3D LEAK SUMMARY:
=3D=3D16880=3D=3D    definitely lost: 16 bytes in 1 blocks.
=3D=3D16880=3D=3D    possibly lost:   0 bytes in 0 blocks.
=3D=3D16880=3D=3D    still reachable: 6912 bytes in 4 blocks.
----------------------------------------------------------

The number which troubles me ist the bytes that are still
reachable. Here's, the detail:

----------------------------------------------------------
=3D=3D19169=3D=3D 6848 bytes in 3 blocks are still reachable in loss =
record 3 of 3
=3D=3D19169=3D=3D    at 0x4015DE3B: __builtin_new (vg_clientfuncs.c:129)
=3D=3D19169=3D=3D    by 0x4015DE76: operator new(unsigned) =
(vg_clientfuncs.c:142)
=3D=3D19169=3D=3D    by 0x40278E00: std::__default_alloc_template<true, =
0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.0)
=3D=3D19169=3D=3D    by 0x40278D1C: std::__default_alloc_template<true, =
0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
=3D=3D19169=3D=3D    by 0x402788EF: std::__default_alloc_template<true, =
0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
=3D=3D19169=3D=3D    by 0x8049008: std::__simple_alloc<int, =
std::__default_alloc_template<true, 0> >::allocate(unsigned) =
(/usr/include/g++/bits/stl_alloc.h:224)
=3D=3D19169=3D=3D    by 0x8048D7E: std::_Vector_alloc_base<int, =
std::allocator<int>, true>::_M_allocate(unsigned) =
(/usr/include/g++/bits/stl_vector.h:121)
=3D=3D19169=3D=3D    by 0x8048A45: std::vector<int, std::allocator<int> =
>::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, =
std::allocator<int> > >, int const&) =
(/usr/include/g++/bits/stl_vector.h:898)
=3D=3D19169=3D=3D    by 0x804884C: std::vector<int, std::allocator<int> =
>::push_back(int const&) (/usr/include/g++/bits/stl_vector.h:496)
=3D=3D19169=3D=3D    by 0x80486A1: f1() (test2.C:10)
=3D=3D19169=3D=3D    by 0x80487A2: main (test2.C:21)
=3D=3D19169=3D=3D    by 0x403094A1: __libc_start_main (in =
/lib/libc.so.6)
=3D=3D19169=3D=3D    by 0x8048580: (within =
/home/bach/work/assembly/htga/src/progs/test)
----------------------------------------------------------

Regarding the program above, I sincerely do think that there should be
no leak at all, even not in "reachable" parts.

Now, a few bytes don't hurt. Unfortunately, when I let run my real
program, here's what I get (for really small data sets):

----------------------------------------------------------
=3D=3D698=3D=3D LEAK SUMMARY:
=3D=3D698=3D=3D    definitely lost: 24825 bytes in 3492 blocks.
=3D=3D698=3D=3D    possibly lost:   1398 bytes in 3 blocks.
=3D=3D698=3D=3D    still reachable: 1125492 bytes in 65 blocks.
----------------------------------------------------------

(please note that I don't care about the that the definitely and
possibly lost numbers, these I can trace back to real oversights in my
code.)

The "still reachable" 1M number is about 40 times greater than the
other two numbers added together and I have the distinct impression
that the memory is really eaten away somewhere:=20
 1) all valgrind detail messages are more or less similar to the one of
    the test case above, all have something to do with containers
 2) putting a "while(1)" loop at a distinctive point in my program
    where everything should have been more or less freed after some
    heavy computation (using about any existing STL container type
    that exists with dozens of different classes) gives me remaining
    memory footprints of >1G (yes, that's gigabyte).

Now my question: any idea where to start searching? is valgrind at
fault (which I don't think, but one never knows)? the gnu STL? the gnu
g++ compiler?

Any suggestion welcome.=20

Regards,
         Bastien

--=20
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The =
debugger=20
for complex code. Debugging C/C++ programs can leave you feeling lost =
and=20
disoriented. TotalView can help you find your way. Available on major =
UNIX=20
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] Scheduler problem

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

Quoting Julian Seward <js...@ac...>:

> Try the patch called 09-rdtsc-calibration from
> http://www.goop.org/~jeremy/valgrind/

I doubt that will help much - that just stops an assertion failure when getting
the calibration.  The basic problem is that the TSC is variable-rate, and
therefore useless as a timebase.

    J

[Valgrind-users] Re: "Reachable" memory, where's the bug (g++, STL, valgrind)?

[Bastien C. <ba...@ch...>]

On Wednesday 09 April 2003 19:37, you wrote:
> My guess is that the STL allocator keeps the memory around. What happen=
s
> if you call f1() several times in main()?

No change, at least for this small example. But I continued to play a bit=
 with=20
containers my program uses and came out with this gem:

------------------------------------------------
#include<iostream>
#include<deque>
#include<set>
using namespace std;

void f1(int ic)
{
  set<char> n;
  for(char c=3D'a'; c < 'z'; c++) n.insert(c);

  deque<set<char> > v;
  for(int i=3D0; i<ic; i++) v.push_back(n);
}

int main(){
  f1(1000);
  cout << "The memory footprint ..." << endl;
  f1(20000);
  cout << "... should be ..." << endl;
  f1(50000);
  cout << "... near zero exactly now! (it isn't *sigh*)" << endl;

  //while(1);

  return 0;
}
------------------------------------------------

Everyone's invited to let this run on their system ...

------------------------------------------------
=3D=3D13669=3D=3D LEAK SUMMARY:
=3D=3D13669=3D=3D    definitely lost: 16 bytes in 1 blocks.
=3D=3D13669=3D=3D    possibly lost:   0 bytes in 0 blocks.
=3D=3D13669=3D=3D    still reachable: 32568232 bytes in 127 blocks.
=3D=3D13669=3D=3D         suppressed: 0 bytes in 0 blocks.
------------------------------------------------

=2E.. and play with it: the numbers get lower when stopping after f1(2000=
) or=20
f1(20000)). Best thing is, when one uncomments the while(1); statement th=
e=20
memory footprint is around 80M (where it shouldn't be much greater than t=
he=20
size of the executable).

I digged the news a bit and found this:=20

http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3Dutf-8&frame=
=3Dright&th=3D432bcc216e83d78f&seekm=3Dslrnaa3v4d.lt.mixtim_nospam%40taco=
=2Emixtim.ispwest.com#link3

Here's one interesting part:

> The default allocator for many c++ standard libraries (such as the one =
that
> ships with gcc) never actually "frees" memory. It just adds the memory =
back
> to a pool for later use. So, if you allocate a map that contains 80 MB
> worth of data and then destroy the map, your application still has that=
 80
> MB allocated and will until your program exits.

On the other hand, after the program exited, valgrind should not find any=
=20
leaks (the STL pool should have been freed, right?). Any ideas?

So the STL is to 'blame'. The description of the pool behaviour should go=
 into=20
the FAQ of valgrind, though, I'm sure other people tripped (are tripping,=
=20
will trip) over that too.

And now for something completely related (but going off topic): is there =
any=20
way to "flush" that pool?=20

Regards,
        Bastien

PS: Did I already thank the valgrind author? No? I longed for a tool like=
 that=20
for Linux since I first worked with purify on a SUN. Thanks a lot.

--=20
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --