valgrind-users — General discussion list for Valgrind users

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

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

On Wed, 2003-04-09 at 15:45, Bastien Chevreux wrote:
> 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=42;
>   vector<int> v;
>   for(int i=0; i<1000000; i++) v.push_back(n);
> }
> 
> int main(){
>   f1();
>   return 0;
> }
> ----------------------------------------------------------
> 
> g++ -g -o test test.C 
> 
> and then 
> 
> valgrind --leak-resolution=high --num-callers=20 --show-reachable=yes --leak-check=yes ./test
> 
> I will get the following summary:
> 
> ----------------------------------------------------------
> ==16880== LEAK SUMMARY:
> ==16880==    definitely lost: 16 bytes in 1 blocks.
> ==16880==    possibly lost:   0 bytes in 0 blocks.
> ==16880==    still reachable: 6912 bytes in 4 blocks.
> ----------------------------------------------------------
> 
> The number which troubles me ist the bytes that are still
> reachable. Here's, the detail:
> 
> ----------------------------------------------------------
> ==19169== 6848 bytes in 3 blocks are still reachable in loss record 3 of 3
> ==19169==    at 0x4015DE3B: __builtin_new (vg_clientfuncs.c:129)
> ==19169==    by 0x4015DE76: operator new(unsigned) (vg_clientfuncs.c:142)
> ==19169==    by 0x40278E00: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.0)
> ==19169==    by 0x40278D1C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
> ==19169==    by 0x402788EF: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
> ==19169==    by 0x8049008: std::__simple_alloc<int, std::__default_alloc_template<true, 0> >::allocate(unsigned) (/usr/include/g++/bits/stl_alloc.h:224)
> ==19169==    by 0x8048D7E: std::_Vector_alloc_base<int, std::allocator<int>, true>::_M_allocate(unsigned) (/usr/include/g++/bits/stl_vector.h:121)
> ==19169==    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)
> ==19169==    by 0x804884C: std::vector<int, std::allocator<int> >::push_back(int const&) (/usr/include/g++/bits/stl_vector.h:496)
> ==19169==    by 0x80486A1: f1() (test2.C:10)
> ==19169==    by 0x80487A2: main (test2.C:21)
> ==19169==    by 0x403094A1: __libc_start_main (in /lib/libc.so.6)
> ==19169==    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):
> 
> ----------------------------------------------------------
> ==698== LEAK SUMMARY:
> ==698==    definitely lost: 24825 bytes in 3492 blocks.
> ==698==    possibly lost:   1398 bytes in 3 blocks.
> ==698==    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: 
>  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. 

My guess is that the STL allocator keeps the memory around. What happens
if you call f1() several times in main()?

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

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

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

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=3Dy=
es --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 reco=
rd 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_clientfunc=
s.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::__defaul=
t_alloc_template<true, 0> >::allocate(unsigned) (/usr/include/g++/bits/st=
l_alloc.h:224)
=3D=3D19169=3D=3D    by 0x8048D7E: std::_Vector_alloc_base<int, std::allo=
cator<int>, true>::_M_allocate(unsigned) (/usr/include/g++/bits/stl_vecto=
r.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. --

Re: [Valgrind-users] Scheduler problem

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

On Wednesday 09 April 2003 7:17 am, Sefer Tov wrote:
> Indeed, you were both correct.
> I am running it on a laptop (compaq armada m300) with apm enabled.
>
> I must admit that this proves to be quite an annoyance, since I do most of
> my work on a laptop. Does that affect the timing of other functions as
> well?
>
> I'm unfailiar with these high resolution time counters in x86, but it
> strikes me odd that Intel wouldn't provide an equivilant, reliable
> mechanism for laptops as well (maybe in exchange of accuracy or slight
> performance impact).
>
> I'm curious, is there any way around this?

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

J


>
> Thanks in advance,
>     Sefer.
>
>
> From: Julian Seward <js...@ac...>
>
> >To: Jeremy Fitzhardinge <je...@go...>, Sefer Tov <se...@ho...>
> >CC: val...@li...
> >Subject: Re: [Valgrind-users] Scheduler problem
> >Date: Tue, 8 Apr 2003 21:24:24 +0000
> >
> >
> >Sefer,
> >
> >I tested the program you sent me (below) and it behaves
> >identically running on V from normal; no timing anomalies.
> >This is running on a 1133Mhz PIII-T (desktop) machine.
> >
> >I suspect Jeremy may be right about the power management thing;
> >he's had a patch available for that for a while.  Can you
> >clarify the situation re power management on your platform?
> >Thanks.
> >
> >J
> >
> >#include <pthread.h>
> >#include <stdio.h>
> >#include <unistd.h>
> >
> >
> >void *start(void *p)
> >{
> >         printf("Hi!\n");
> >         sleep(1);
> >         printf("Here\n");
> >         sleep(1);
> >
> >         return 0;
> >}
> >
> >
> >int main()
> >{
> >         pthread_t tid;
> >         void *p;
> >         int i;
> >
> >         for ( i = 0; i < 5; ++i ) {
> >                 pthread_create(&tid, 0, start, 0);
> >         }
> >         pthread_join(tid, &p);
> >
> >         return 0;
> >}
> >
> >On Tuesday 08 April 2003 10:12 am, Jeremy Fitzhardinge wrote:
> > > Quoting Sefer Tov <se...@ho...>:
> > > > Hi!
> > > >
> > > > I've been testing a short threaded program, and I noticed that
> >
> >sleep(x),
> >
> > > > although utilizes no cpu, it schdules poorly (the program slows down
> > > > almost
> > > > to a halt).
> > >
> > > Is your machine a laptop, or a desktop with power management enabled?
> > > Valgrind uses the TSC register as its timebase, and I've noticed on my
> > > laptop the TSC doesn't advance when the machine is idle.  You can
> > > easily tell if this is the case: if you run a CPU-bound program at the
> > > same
> >
> >time,
> >
> > > then the TSC advances at near full speed and the sleeps are for the
> >
> >right
> >
> > > time.
> > >
> > > 	J
>
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail

Re: [Valgrind-users] Scheduler problem

[Sefer T. <se...@ho...>]

Indeed, you were both correct.
I am running it on a laptop (compaq armada m300) with apm enabled.

I must admit that this proves to be quite an annoyance, since I do most of 
my work on a laptop. Does that affect the timing of other functions as well?

I'm unfailiar with these high resolution time counters in x86, but it 
strikes me odd that Intel wouldn't provide an equivilant, reliable mechanism 
for laptops as well (maybe in exchange of accuracy or slight performance 
impact).

I'm curious, is there any way around this?

Thanks in advance,
    Sefer.


>From: Julian Seward <js...@ac...>
>To: Jeremy Fitzhardinge <je...@go...>, Sefer Tov <se...@ho...>
>CC: val...@li...
>Subject: Re: [Valgrind-users] Scheduler problem
>Date: Tue, 8 Apr 2003 21:24:24 +0000
>
>
>Sefer,
>
>I tested the program you sent me (below) and it behaves
>identically running on V from normal; no timing anomalies.
>This is running on a 1133Mhz PIII-T (desktop) machine.
>
>I suspect Jeremy may be right about the power management thing;
>he's had a patch available for that for a while.  Can you
>clarify the situation re power management on your platform?
>Thanks.
>
>J
>
>#include <pthread.h>
>#include <stdio.h>
>#include <unistd.h>
>
>
>void *start(void *p)
>{
>         printf("Hi!\n");
>         sleep(1);
>         printf("Here\n");
>         sleep(1);
>
>         return 0;
>}
>
>
>int main()
>{
>         pthread_t tid;
>         void *p;
>         int i;
>
>         for ( i = 0; i < 5; ++i ) {
>                 pthread_create(&tid, 0, start, 0);
>         }
>         pthread_join(tid, &p);
>
>         return 0;
>}
>
>On Tuesday 08 April 2003 10:12 am, Jeremy Fitzhardinge wrote:
> > Quoting Sefer Tov <se...@ho...>:
> > > Hi!
> > >
> > > I've been testing a short threaded program, and I noticed that 
>sleep(x),
> > >
> > > although utilizes no cpu, it schdules poorly (the program slows down
> > > almost
> > > to a halt).
> >
> > Is your machine a laptop, or a desktop with power management enabled?
> > Valgrind uses the TSC register as its timebase, and I've noticed on my
> > laptop the TSC doesn't advance when the machine is idle.  You can easily
> > tell if this is the case: if you run a CPU-bound program at the same 
>time,
> > then the TSC advances at near full speed and the sleeps are for the 
>right
> > time.
> >
> > 	J
>


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Valgrind-users] Scheduler problem

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

Sefer,

I tested the program you sent me (below) and it behaves
identically running on V from normal; no timing anomalies.
This is running on a 1133Mhz PIII-T (desktop) machine.

I suspect Jeremy may be right about the power management thing;
he's had a patch available for that for a while.  Can you 
clarify the situation re power management on your platform?
Thanks.

J

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>


void *start(void *p)
{
        printf("Hi!\n");
        sleep(1);
        printf("Here\n");
        sleep(1);

        return 0;
}


int main()
{
        pthread_t tid;
        void *p;
        int i;

        for ( i = 0; i < 5; ++i ) {
                pthread_create(&tid, 0, start, 0);
        }
        pthread_join(tid, &p);

        return 0;
}

On Tuesday 08 April 2003 10:12 am, Jeremy Fitzhardinge wrote:
> Quoting Sefer Tov <se...@ho...>:
> > Hi!
> >
> > I've been testing a short threaded program, and I noticed that sleep(x),
> >
> > although utilizes no cpu, it schdules poorly (the program slows down
> > almost
> > to a halt).
>
> Is your machine a laptop, or a desktop with power management enabled? 
> Valgrind uses the TSC register as its timebase, and I've noticed on my
> laptop the TSC doesn't advance when the machine is idle.  You can easily
> tell if this is the case: if you run a CPU-bound program at the same time,
> then the TSC advances at near full speed and the sleeps are for the right
> time.
>
> 	J

Re: [Valgrind-users] Scheduler problem

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

Quoting Sefer Tov <se...@ho...>:

> Hi!
> 
> I've been testing a short threaded program, and I noticed that sleep(x),
> 
> although utilizes no cpu, it schdules poorly (the program slows down
> almost 
> to a halt).

Is your machine a laptop, or a desktop with power management enabled?  Valgrind 
uses the TSC register as its timebase, and I've noticed on my laptop the TSC 
doesn't advance when the machine is idle.  You can easily tell if this is the 
case: if you run a CPU-bound program at the same time, then the TSC advances at 
near full speed and the sleeps are for the right time.

	J

[Valgrind-users] Scheduler problem

[Sefer T. <se...@ho...>]

Hi!

I've been testing a short threaded program, and I noticed that sleep(x), 
although utilizes no cpu, it schdules poorly (the program slows down almost 
to a halt).

This is a simple threaded queue handler program, which sleeps 2 sec. between 
each update to the queue, however, after 2-3 such updates, the sleep seems 
to triple (or worse) waiting often 10 seconds or more (while being 
completely idle).

This happens to me on Mandrake 9.1 on i686 running valgrind both 1.9.4 and a 
recent snapshot from the CVS.

This might indicate some problem in scheduling blocking commands in general 
(or sleep in particular), after all, why should a sleep(2) wait for 10 
seconds (while the cpu is entirely idle).

If anyone has any ideas or can offer an explanation, I'd appreciate your 
comments.

Thanks,
    Sefer.


####  Makefile
all:
        gcc -g -Wall -D_REENTRANT -o go *.c -lpthread



####  test.c

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>



#define MAXT			4
#define MAXD			10



typedef struct
{
	pthread_mutex_t		my_mutex;
	pthread_cond_t		my_cond;
	int			count;
} data_t;




static data_t			gdata[MAXT];




static void data_add(data_t *data)
{
	pthread_mutex_lock(&data->my_mutex);

	while ( data->count >= MAXD ) {
		pthread_cond_wait(&data->my_cond, &data->my_mutex);
	}


	if ( !data->count )
		pthread_cond_signal(&data->my_cond);

	++data->count;

	pthread_mutex_unlock(&data->my_mutex);
}



static void data_remove(data_t *data)
{
	pthread_mutex_lock(&data->my_mutex);

	while ( data->count == 0 ) {
		pthread_cond_wait(&data->my_cond, &data->my_mutex);
	}

	if ( data->count >= MAXD ) pthread_cond_signal(&data->my_cond);
	--data->count;

	pthread_mutex_unlock(&data->my_mutex);
}



static void *thread_proc(void *ptr)
{
	printf("Thread created!\n");

	for ( ; ; ) {
		data_remove((data_t *) ptr);
		printf("Got some data.\n");
	}

	return NULL;
}



static void run()
{
	int i, rc;
	pthread_t tid;

	for ( i = 0; i < MAXT; ++i ) {
		pthread_mutex_init(&gdata[i].my_mutex,  NULL);
		pthread_cond_init(&gdata[i].my_cond, NULL);
		gdata[i].count = 0;

		rc = pthread_create(&tid, NULL, thread_proc, gdata + i);
	}

	for ( ; ; ) {
		data_add(gdata + 0);
		data_add(gdata + 1);
		sleep(2);
	}
}



int main()
{
	run();
	return 0;
}

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

[Valgrind-users] Re: Automatic suppression generation, plus some docs comments

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

On Tue, 18 Mar 2003, Nicholas Nethercote wrote:

> I've just hacked up support for automatic suppression generation.  If
> everyone likes it, I will commit it to the HEAD.

I just committed it along with some other changes.  I hope I haven't
broken anything.  Please try it out.

> Some notes:
>   - option name is --gen-suppressions=yes

N

[Valgrind-users] valgrind-1.9.5 is available ...

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

... from the usual place, http://developer.kde.org/~sewardj

The release notes follow.

J



Version 1.9.5 (7 April 2003)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It occurs to me that it would be helpful for valgrind users to record
in the source distribution the changes in each release.  So I now
attempt to mend my errant ways :-)  Changes in this and future releases
will be documented in the NEWS file in the source distribution.

Major changes in 1.9.5:

- (Critical bug fix): Fix a bug in the FPU simulation.  This was
  causing some floating point conditional tests not to work right.
  Several people reported this.  If you had floating point code which
  didn't work right on 1.9.1 to 1.9.4, it's worth trying 1.9.5.

- Partial support for Red Hat 9.  RH9 uses the new Native Posix 
  Threads Library (NPTL), instead of the older LinuxThreads.  
  This potentially causes problems with V which will take some
  time to correct.  In the meantime we have partially worked around
  this, and so 1.9.5 works on RH9.  Threaded programs still work,
  but they may deadlock, because some system calls (accept, read,
  write, etc) which should be nonblocking, in fact do block.  This
  is a known bug which we are looking into.

  If you can, your best bet (unfortunately) is to avoid using 
  1.9.5 on a Red Hat 9 system, or on any NPTL-based distribution.
  If your glibc is 2.3.1 or earlier, you're almost certainly OK.

Minor changes in 1.9.5:

- Added some #errors to valgrind.h to ensure people don't include
  it accidentally in their sources.  This is a change from 1.0.X
  which was never properly documented.  The right thing to include
  is now memcheck.h.  Some people reported problems and strange
  behaviour when (incorrectly) including valgrind.h in code with 
  1.9.1 -- 1.9.4.  This is no longer possible.

- Add some __extension__ bits and pieces so that gcc configured
  for valgrind-checking compiles even with -Werror.  If you
  don't understand this, ignore it.  Of interest to gcc developers
  only.

- Removed a pointless check which caused problems interworking 
  with Clearcase.  V would complain about shared objects whose
  names did not end ".so", and refuse to run.  This is now fixed.
  In fact it was fixed in 1.9.4 but not documented.

- Fixed a bug causing an assertion failure of "waiters == 1"
  somewhere in vg_scheduler.c, when running large threaded apps,
  notably MySQL.

- Add support for the munlock system call (124).

Some comments about future releases:

1.9.5 is, we hope, the most stable Valgrind so far.  It pretty much
supersedes the 1.0.X branch.  If you are a valgrind packager, please
consider making 1.9.5 available to your users.  You can regard the
1.0.X branch as obsolete: 1.9.5 is stable and vastly superior.  There
are no plans at all for further releases of the 1.0.X branch.

If you want a leading-edge valgrind, consider building the cvs head
(from SourceForge), or getting a snapshot of it.  Current cool stuff
going in includes MMX support (done); SSE/SSE2 support (in progress),
a significant (10-20%) performance improvement (done), and the usual
large collection of minor changes.  Hopefully we will be able to
improve our NPTL support, but no promises.

Re: [Valgrind-users] profiling/debugging inside shared objects

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

On Mon, 7 Apr 2003, Josef Weidendorfer wrote:

> > Another approach:  I've been thinking about, and half-implemented, this
> > solution: when a program munmap()s an executable segment, Valgrind doesn't
> > really munmap it, but just leaves it in that address space.  Then the
> > symbols don't get unloaded.  The only downside is that it wastes address
> > space, but hopefully code sizes aren't so big that this is a problem.
>
> I really see a problem if an application loads the same plugin multiple times
> in a row, and you get thus one plugin mapped multiple times simultaniously.
> E.g. in KDevelop (a C++ IDE), every feature for project development is in a
> plugin. Now every time you open another project, the plugins of the old
> project are unmapped and the plugins of the new one are mapped (around 20).

Urgh.

> > One problem is that debug info is currently read in lazily, which clashes
> > with this, for tedious reasons. Getting back to this is somewhere in the
>
> Why? If the same plugin is loaded at mostly once, I don't see a problem.

It's a problem for Memcheck:  if you have a leak in foo.so, often foo.so
is dlclose()d before the program ends, currently the leak checker gives
hopeless error messages about foo.so because the debug info has been
unloaded.

Now imagine I've implemented the don't-unload-the-symbols scheme, but
there are no other errors in the program using foo.so.  So the first time
the debug info for foo.so is needed is during the leak check.  But by this
time, foo.so has already been loaded and unloaded, its debug info was
never read (because it wasn't needed) and the error message is still
uninformative.  If debug info was needed even once before foo.so was
dlclose()d there would be no problem, but we can't rely on that.

N

Re: [Valgrind-users] profiling/debugging inside shared objects

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

On Monday 07 April 2003 16:55, Nicholas Nethercote wrote:
> On Mon, 7 Apr 2003, Josef Weidendorfer wrote:
> > > Hmm, in theory there should be no problems, Valgrind (and hence
> > > Cachegrind) can handle dlopen'd plugins ok...
> >
> > But they are unmapped before program termination. You only get one cost
> > line "discarded" for all plugins. The solution would be to allow dumping
> > while the plugin is mapped. Or you dump the information of BBCCs when the
> > according object is unmapped.
> >
> > Or you don't delete BBCCs and accumate cost to "discarded", but keep
> > them. Now you have the problem that a BB start address isn't unique to
> > get to the right BBCC, but you have to store the SegInfo* in the BBCCs to
> > distinguish among BBs from different plugins at the same address.
> >
> > BTW, my Calltree skin should be buggy in this regard, as it doesn't
> > delete any BBCCs on unmapping, but still only uses the BB address. But
> > checking the SegInfo* should be easy enough for a fix.
> > Perhaps it's even better to take BBCCs of unmapped objects from the hash
> > into a list, and put them in again if the object is mapped again after
> > adjusting the addresses if needed. The same object could be mapped on a
> > different base address.
>
> Another approach:  I've been thinking about, and half-implemented, this
> solution: when a program munmap()s an executable segment, Valgrind doesn't
> really munmap it, but just leaves it in that address space.  Then the
> symbols don't get unloaded.  The only downside is that it wastes address
> space, but hopefully code sizes aren't so big that this is a problem.

I really see a problem if an application loads the same plugin multiple times 
in a row, and you get thus one plugin mapped multiple times simultaniously.
E.g. in KDevelop (a C++ IDE), every feature for project development is in a 
plugin. Now every time you open another project, the plugins of the old 
project are unmapped and the plugins of the new one are mapped (around 20).

It's easy to keep a list of objects the application has unmapped, and in a 
mmap, eventually return the already mapped object if a plugin is loaded a 
second time.

> One problem is that debug info is currently read in lazily, which clashes
> with this, for tedious reasons. Getting back to this is somewhere in the

Why? If the same plugin is loaded at mostly once, I don't see a problem.

Josef

> lower half of my ever-growing todo list...
>
> N
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
--
Dipl.-Inform. Josef Weidendorfer
LRR-TUM - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454

Re: [Valgrind-users] profiling/debugging inside shared objects

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

On Mon, 7 Apr 2003, Josef Weidendorfer wrote:

> > Hmm, in theory there should be no problems, Valgrind (and hence
> > Cachegrind) can handle dlopen'd plugins ok...
>
> But they are unmapped before program termination. You only get one cost line
> "discarded" for all plugins. The solution would be to allow dumping while the
> plugin is mapped. Or you dump the information of BBCCs when the according
> object is unmapped.
>
> Or you don't delete BBCCs and accumate cost to "discarded", but keep them.
> Now you have the problem that a BB start address isn't unique to get to the
> right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish
> among BBs from different plugins at the same address.
>
> BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any
> BBCCs on unmapping, but still only uses the BB address. But checking the
> SegInfo* should be easy enough for a fix.
> Perhaps it's even better to take BBCCs of unmapped objects from the hash into
> a list, and put them in again if the object is mapped again after adjusting
> the addresses if needed. The same object could be mapped on a different base
> address.

Another approach:  I've been thinking about, and half-implemented, this
solution: when a program munmap()s an executable segment, Valgrind doesn't
really munmap it, but just leaves it in that address space.  Then the
symbols don't get unloaded.  The only downside is that it wastes address
space, but hopefully code sizes aren't so big that this is a problem.
One problem is that debug info is currently read in lazily, which clashes
with this, for tedious reasons. Getting back to this is somewhere in the
lower half of my ever-growing todo list...

N

[Valgrind-users] Big Valgrind speedup just committed to CVS head

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

Hi,

I just committed a change to the CVS head that speeds up the Memcheck and
Addrcheck skins a lot:  by up to 28% and 36% respectively.  Here are some
figures for the SPEC2000 benchmark suite, using the "test" inputs:

========
memcheck
========
    164.gzip: vg1: 46.00s,   vg2: 37.12s,   speed-up: 19.3%
   300.twolf: vg1: 7.34s,    vg2: 6.63s,    speed-up: 9.7%
  197.parser: vg1: 70.60s,   vg2: 57.24s,   speed-up: 18.9%
  186.crafty: vg1: 166.83s,  vg2: 156.80s,  speed-up: 6.0%
  255.vortex: vg1: 392.94s,  vg2: 283.37s,  speed-up: 27.9%
   256.bzip2: vg1: 152.97s,  vg2: 141.28s,  speed-up: 7.6%
     176.gcc: vg1: 60.27s,   vg2: 52.06s,   speed-up: 13.6%
     181.mcf: vg1: 4.24s,    vg2: 4.11s,    speed-up: 3.1%
     254.gap: vg1: 31.40s,   vg2: 24.73s,   speed-up: 21.2%
--------
     179.art: vg1: 364.32s,  vg2: 373.53s,  speed-up: -2.5%
  183.equake: vg1: 68.86s,   vg2: 63.54s,   speed-up: 7.7%
    188.ammp: vg1: 463.18s,  vg2: 455.46s,  speed-up: 1.7%
    177.mesa: vg1: 113.69s,  vg2: 100.01s,  speed-up: 12.0%

========
addrcheck
========
    164.gzip: vg1: 35.97s,   vg2: 27.37s,   speed-up: 23.9%
   300.twolf: vg1: 5.18s,    vg2: 4.48s,    speed-up: 13.5%
  197.parser: vg1: 57.92s,   vg2: 40.95s,   speed-up: 29.3%
  186.crafty: vg1: 119.23s,  vg2: 93.99s,   speed-up: 21.2%
  255.vortex: vg1: 349.38s,  vg2: 223.08s,  speed-up: 36.1%
   256.bzip2: vg1: 105.23s,  vg2: 90.89s,   speed-up: 13.6%
     176.gcc: vg1: 43.52s,   vg2: 33.97s,   speed-up: 21.9%
     181.mcf: vg1: 2.20s,    vg2: 2.07s,    speed-up: 5.9%
     254.gap: vg1: 22.90s,   vg2: 17.82s,   speed-up: 22.2%
--------
     179.art: vg1: 298.79s,  vg2: 294.92s,  speed-up: 1.3%
  183.equake: vg1: 59.73s,   vg2: 57.94s,   speed-up: 3.0%
    188.ammp: vg1: 404.55s,  vg2: 399.96s,  speed-up: 1.1%
    177.mesa: vg1: 92.93s,   vg2: 79.65s,   speed-up: 14.3%

For those of you interested in the details:  the speed-up was possible
because the skins' handling of %esp updates was decidedly sub-optimal...
every %esp adjustment requires updating the accessibility bits of the
relevant stack words.  This was handled with the core events
{new,die}_stack_mem{_aligned,}, after the core computed the %esp-delta at
run-time.  And %esp is updated very frequently.

But most of the time the %esp-delta can be computed at compile time, which
saves an extra function call.  Now %esp updates are handled with
{new,die}_stack_mem, and optionally the specialised versions
{new,die}_stack_mem_{4,8,12,16,32}.  The core uses these specialised
versions if they are present, or falls back to the generic version if not,
or if the delta cannot be determined at compile time.  Addrcheck and
Memcheck have unrolled-loop versions for the specialised cases.

Thanks to Julian for pointing out the inefficiency in the old approach.

I haven't tested this super-thoroughly, so I would appreciate it if others
could try it out.  I would also be interested to hear what kind of
speed-ups others get on different machines, environments, etc.

Also, since a few things got moved around in the source, this might cause
some CVS clashes with those of actively hacking Valgrind;  apologies if
so, but I hope you agree the performance improvements are worth it.

N

Re: [Valgrind-users] profiling/debugging inside shared objects

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

On Monday 07 April 2003 14:40, Nicholas Nethercote wrote:
> On Fri, 4 Apr 2003, Charlls Quarra wrote:
> >  I wonder if there are issues about profiling
> > dinamically loaded plugins? valgrind --skin=cachegrind
> > doesnt seem to produce any relevant info about code in
> > those plugins, only code in statically linked
> > libraries
>
> Hmm, in theory there should be no problems, Valgrind (and hence
> Cachegrind) can handle dlopen'd plugins ok...

But they are unmapped before program termination. You only get one cost line 
"discarded" for all plugins. The solution would be to allow dumping while the 
plugin is mapped. Or you dump the information of BBCCs when the according 
object is unmapped.

Or you don't delete BBCCs and accumate cost to "discarded", but keep them.
Now you have the problem that a BB start address isn't unique to get to the 
right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish 
among BBs from different plugins at the same address.

BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any 
BBCCs on unmapping, but still only uses the BB address. But checking the 
SegInfo* should be easy enough for a fix.
Perhaps it's even better to take BBCCs of unmapped objects from the hash into 
a list, and put them in again if the object is mapped again after adjusting 
the addresses if needed. The same object could be mapped on a different base 
address.

Josef


>
> N
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] profiling/debugging inside shared objects

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

On Fri, 4 Apr 2003, Charlls Quarra wrote:

>  I wonder if there are issues about profiling
> dinamically loaded plugins? valgrind --skin=cachegrind
> doesnt seem to produce any relevant info about code in
> those plugins, only code in statically linked
> libraries

Hmm, in theory there should be no problems, Valgrind (and hence
Cachegrind) can handle dlopen'd plugins ok...

N

Re: [Valgrind-users] Need a configure check for NPTL

[Robert W. <rj...@du...>]

> IIRC, the wine folks have a reasonable configure time check for NPTL in
> CVS, so maybe you can simply swipe their code ?

I can't find that.  I can see a --with-nptl switch, but no automated
check.  If doing it the automated way is too difficult, maybe having a
--with-nptl switch is the way to go?

Regards,
 Robert.

--=20
Robert Walsh
Amalgamated Durables, Inc.  -  "We don't make the things you buy."
Email: rj...@du...

Re: [Valgrind-users] Need a configure check for NPTL

[Robert W. <rj...@du...>]

> Now what?  If the symbol is in the DSO, why can't I link to it?
> Mystified.

You seem to be saying "Mystified" a lot about the NPTL :-)  This does
seem strange, though.  Are you sure you're picking up the correct
library?  Maybe you need to say "extern int pthread_join_np();" instead
of just "extern int pthread_join_np;" (i.e. declare it as an external
function and not variable.)  I haven't checked, so this may be a red
herring.

BTW: my file-descriptor leakage support is almost ready.  I'm just
testing the "passing fds over a unix-domain socket" support at the
moment.  Sockets are weird.

Regards,
 Robert.

--=20
Robert Walsh
Amalgamated Durables, Inc.  -  "We don't make the things you buy."
Email: rj...@du...

Re: [Valgrind-users] Need a configure check for NPTL

[Biswapesh C. <bis...@tc...>]

IIRC, the wine folks have a reasonable configure time check for NPTL in
CVS, so maybe you can simply swipe their code ?

Of course, the issue they are facing is that what if the program
(wine/valgrind) is compiled with one kind of threading support and the
binary shipped to a system with a different type of threading ?
Basically, in that case, you need a runtime check as well.

> On Sunday 06 April 2003 6:48 pm, Robert Walsh wrote:
> > > Anyone have a reliable check easily to hand?
> >
> > Yeugh.  I don't know if this is reliable, but pthread_tryjoin_np is
> > implemented in nptl but not in the original pthread stuff.  Perhaps a
> > check for that will let you know?  It will certainly let you know if
> > pthread_tryjoin_np is implemented, but you might allow yourself to infer
> > from that that it's nptl... :-)
> 
> Hmm.  Sounds a plausible scheme, but ...
> 
> On the one hand (on RH 9),   nm /lib/tls/libpthread.so.0 | grep tryjoin
> shows pthread_tryjoin_np as an exported text symbol ("T").
> 
> On the other hand, you can't link against it:
> 
>    sewardj@localhost:~/VgHEAD/valgrind$ cat nptltest.c
> 
>    #include <pthread.h>
>    extern int pthread_tryjoin_np;
>    int main (int argc, char * argv )
>    {
>       int* p = (int*)(& pthread_tryjoin_np);
>       return 0;
>    }
> 
>    sewardj@localhost:~/VgHEAD/valgrind$ gcc -o nptltest nptltest.c
>    -lpthread
>    /tmp/ccWjnvw9.o(.text+0x13): In function `main':
>    : undefined reference to `pthread_tryjoin_np'
>    collect2: ld returned 1 exit status
> 
> Now what?  If the symbol is in the DSO, why can't I link to it?
> Mystified.
> 
> J
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
-- 
Biswa.

[Valgrind-users] (p)write problem

[Ranko Z. <ra...@sp...>]

Hi All,

First of all I would like to thank Julian for making this tool available. It is 
great!

I'm addressing you because I'm experiencing something that for last two days 
drove me completely bannanas.

I was checking one of my multithreaded app. against the Valgrind, found few 
mistakes and cleaned some of them up - but some of them I simply cannot 
understand how do they happen. And I was hoping that some of you might have 
expirienced the same - and found the solution. Basically, when I'm writing to a 
file via either write or pwrite I can see in gdb that I'm passing the correct 
pointers, but when libc performs a syscall, the buffer pointer gets somehow 
shifted for one byte inside the allocated buffer and crossing the allocated 
space thus having Valgrind complain about it. The behavior is not consistent 
because at some places pwrite works like a charm and at certain places it does 
this funny stuff.

The error Valgrind gives is "Address 0x412C72B9 is 1 bytes inside a block of 
size 32 alloc'd" and the address offset is exactly 1 bytes from what I have 
passed to the pwrite according to gdb (0x412C72B8). I also see that Valgrind 
passes the same correct pointer to the library (at vg_libpthread.c:2142).

The same error is being reported by both 1.0.4 and 1.9.4.

What could be the cause of this behavior? Btw, application seems to be working 
fine without the Valgrind because the resulting files are correct in the format 
and the content (they are not missing the first byte or something), but then 
again, I'm afraid that I might be corrupting something someplace that could 
fire back afterwards.

I've also tried to reproduce the problem in a smaller program, but 
unfortunately with no luck there.

Thanks in advance,

Ranko


-- 
Ranko Zivojnovic,
NOC Manager              ra...@sp...
Network Operations Center

Spidernet Services Ltd., Tel: +357 22 844844
Nicosia, Cyprus          FAX: +357 22 669470

Re: [Valgrind-users] Need a configure check for NPTL

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

On Sunday 06 April 2003 6:48 pm, Robert Walsh wrote:
> > Anyone have a reliable check easily to hand?
>
> Yeugh.  I don't know if this is reliable, but pthread_tryjoin_np is
> implemented in nptl but not in the original pthread stuff.  Perhaps a
> check for that will let you know?  It will certainly let you know if
> pthread_tryjoin_np is implemented, but you might allow yourself to infer
> from that that it's nptl... :-)

Hmm.  Sounds a plausible scheme, but ...

On the one hand (on RH 9),   nm /lib/tls/libpthread.so.0 | grep tryjoin
shows pthread_tryjoin_np as an exported text symbol ("T").

On the other hand, you can't link against it:

   sewardj@localhost:~/VgHEAD/valgrind$ cat nptltest.c

   #include <pthread.h>
   extern int pthread_tryjoin_np;
   int main (int argc, char * argv )
   {
      int* p = (int*)(& pthread_tryjoin_np);
      return 0;
   }

   sewardj@localhost:~/VgHEAD/valgrind$ gcc -o nptltest nptltest.c -lpthread
   /tmp/ccWjnvw9.o(.text+0x13): In function `main':
   : undefined reference to `pthread_tryjoin_np'
   collect2: ld returned 1 exit status

Now what?  If the symbol is in the DSO, why can't I link to it?
Mystified.

J

vgIntercept not working (was Re: [Valgrind-users] valgrind and poll())

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

Ok, I've got the same problem running OpenOffice on R H 9, using the
LD_ASSUME_KERNEL thing and auxinfo patch from Graydon.

OO is blocking in accept().  We get to accept() at vg_intercept.c:140
(correct), which then calls VGL_(accept) (correct).  Unfortunately this
leads to the one in the same file rather than the one in
vg_libpthread.c.  Enquiring with LD_DEBUG=files confirms that ld.so
has somehow done this, despite both valgrind.so and vg_libpthread.so
being in the image.

Graydon, Jeff, is there any known issue in glibc-2.3.2 to do with weak
symbols not being overriden by non-weak symbols?  What we've got here is
just such a case. 

Mystified.

J


On Thursday 03 April 2003 6:56 am, da...@2g... wrote:
> Quoting Jeremy Fitzhardinge <je...@go...>:
> > On Wed, 2003-04-02 at 10:28, David Eriksson wrote:
> > > Strace stops in poll, and if I attach to the server process with gdb I
> > > get this stacktrace:
> > >
> > > (gdb) bt
> > > #0  0x40183272 in vgPlain_do_syscall () from
> > > /usr/local/lib/valgrind/valgrind.so
> > > #1  0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0
> > > #2  0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60)
> > > at vg_intercept.c:194
> > > #3  0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0
> > > #4  0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
> > > #5  0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
> > > #6  0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616
> > > #7  0x403d3907 in __libc_start_main () from /lib/libc.so.6
> >
> > Hm, looks like the vg_intercept stuff isn't working - it's catching
> > poll, but it isn't passing it into the threads library properly.  What
> > does ldd <your program> say?  What is in /proc/<pid>/maps when you run
> > it?  What does the link command line look like?
>
> ldd says this:
>
>         libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4002a000)
>         libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4002e000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x40054000)
>         libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x400a6000)
>         liblber.so.2 => /usr/lib/liblber.so.2 (0x400d4000)
>         libradiusclient.so.0 =>
> /usr/local/radiusclient/lib/libradiusclient.so.0 (0x400df000)
>         libssl.so.2 => /lib/libssl.so.2 (0x400e8000)
>         libcrypto.so.2 => /lib/libcrypto.so.2 (0x40119000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x401ed000)
>         libc.so.6 => /lib/libc.so.6 (0x401ff000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>         libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4033c000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40347000)
>         libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4034a000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0x40352000)
>         libpam.so.0 => /lib/libpam.so.0 (0x4037f000)
>
> The output from /proc/<pid>/maps is attached.
>
> The (short version) of the linking is simply like this:
>
> gcc  -o server  <OBJECTS> `glib-config --libs gthread` <LIBRARIES>
>
> > Did you manage to get a small standalone program to reproduce the
> > problem?
>
> Not yet.
>
> \David

Re: [Valgrind-users] Need a configure check for NPTL

[Robert W. <rj...@du...>]

> Anyone have a reliable check easily to hand?

Yeugh.  I don't know if this is reliable, but pthread_tryjoin_np is
implemented in nptl but not in the original pthread stuff.  Perhaps a
check for that will let you know?  It will certainly let you know if
pthread_tryjoin_np is implemented, but you might allow yourself to infer
from that that it's nptl... :-)

Regards,
 Robert.

--=20
Robert Walsh
Amalgamated Durables, Inc.  -  "We don't make the things you buy."
Email: rj...@du...

[Valgrind-users] Need a configure check for NPTL

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

Greetings, all.

I'm trying to add support to V for R H 9, and it nearly works.

I need a configure (autoconf, etc) check to establish whether 
V is being built on a system which uses NPTL (Native Posix
Threads Library) as opposed to the older LinuxThreads library.

So far R H 9 is the only distro I'm aware of that uses NPTL.

Problem is: I have a set of patches which does appear to make
V work on R H 9, but they break all other systems.  So I need
a configure test to distinguish NPTL-based systems from
LinuxThreads-based systems.

Anyone have a reliable check easily to hand?

J

[Valgrind-users] Re: some problem

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

On Saturday 05 April 2003 9:25 am, you wrote:
> HI:
> I've been using valgrind for just few days, and it's done well in
> one-thread environment,but when I used it in mutil-threads condition,i got
> some problem.Maybe i use it wrongly,but i don't get where it is. in this
> case,when i link programme with librt.so and libpthread.so and use valgrind
> to find memory leak, i could always get some error message like followed:

> error: /lib/librt.so.1: symbol __pthread_clock_settime, version
> GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference

> I have modifed the LD_PRELOAD var in /usr/local/bin/valgrind shell file,and
> make sure ld load our modified libphread.so first. valgrind version: 1.9.4
> My compiler: g++ 2.96.
> LD_PRELOAD in /usr/local/bin/valgind:

It's a problem which is not easy to fix.  Really the problem is that
/lib/librt.so.1 refers to some symbols __pthread_clock_settime and
__pthread_clock_gettime in /lib/libpthread.so which are not intended 
to be exported, ie they are private.

Best solution is to ensure your program does not use /lib/librt.so.1.

You might be able to fix it by playing around with coregrind/vg_libpthread.vs.
Things to try:

Remove this

   GLIBC_PRIVATE {
      __pthread_clock_gettime;
      __pthread_clock_settime;
   };

or maybe remove this

   GLIBC_2.2.3 {
      __pthread_clock_gettime;
      __pthread_clock_settime;
   } GLIBC_2.2;

or maybe add this

   GLIBC_2.2.4 {
      __pthread_clock_gettime;
      __pthread_clock_settime;
   } GLIBC_2.2;

   GLIBC_2.2.5 {
      __pthread_clock_gettime;
      __pthread_clock_settime;
   } GLIBC_2.2;

or some combination of the above.  After each change you need to
delete coregrind/libpthread.so and do make && make install.

I just don't know if any of the above will work.  If you can find a solution
which works, I would be interested to hear it.

J

[Valgrind-users] pthread.so problem

[chen y. <ch...@ga...>]

SEk6DQpJJ3ZlIGJlZW4gdXNpbmcgdmFsZ3JpbmQgZm9yIGp1c3QgZmV3IGRheXMsIGFuZCBpdCdz
IGRvbmUgd2VsbCBpbiBvbmUtdGhyZWFkIGVudmlyb25tZW50LGJ1dCB3aGVuIEkgdXNlZCBpdCBp
biBtdXRpbC10aHJlYWRzIGNvbmRpdGlvbixpIGdvdCBzb21lIHByb2JsZW0uTWF5YmUgaSB1c2Ug
aXQgd3JvbmdseSxidXQgaSBkb24ndCBnZXQgd2hlcmUgaXQgaXMuDQppbiB0aGlzIGNhc2Usd2hl
biBpIGxpbmsgcHJvZ3JhbW1lIHdpdGggbGlicnQuc28gYW5kIGxpYnB0aHJlYWQuc28gYW5kIHVz
ZSB2YWxncmluZCB0byBmaW5kIG1lbW9yeSBsZWFrLCBpIGNvdWxkIGFsd2F5cyBnZXQgc29tZSBl
cnJvciBtZXNzYWdlIGxpa2UgZm9sbG93ZWQ6IA0KZXJyb3I6IC9saWIvbGlicnQuc28uMTogc3lt
Ym9sIF9fcHRocmVhZF9jbG9ja19zZXR0aW1lLCB2ZXJzaW9uIEdMSUJDX1BSSVZBVEUgbm90IGRl
ZmluZWQgaW4gZmlsZSBsaWJwdGhyZWFkLnNvLjAgd2l0aCBsaW5rIHRpbWUgcmVmZXJlbmNlDQog
ICAgSSBoYXZlIG1vZGlmZWQgdGhlIExEX1BSRUxPQUQgdmFyIGluIC91c3IvbG9jYWwvYmluL3Zh
bGdyaW5kIHNoZWxsIGZpbGUsYW5kIG1ha2Ugc3VyZSBsZCBsb2FkIG91ciBtb2RpZmllZCBsaWJw
aHJlYWQuc28gZmlyc3QuDQp2YWxncmluZCB2ZXJzaW9uOiAxLjkuNA0KTXkgY29tcGlsZXI6IGcr
KyAyLjk2Lg0KTERfUFJFTE9BRCBpbiAvdXNyL2xvY2FsL2Jpbi92YWxnaW5kOiAkVkFMR1JJTkQv
JHNraW5fc286JFZBTEdSSU5EL3ZhbGdyaW5kLnNvOiRWQUxHUklORC9saWJwdGhyZWFkLnNvOiRM
RF9QUkVMT0FEDQoNClRoYW5rcyBpbiBhZHZhbmNlDQpjaGVueWkgDQo=