valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

[Maarten B. <maa...@mi...>]

Hi,

Thanks! Silly me, completely missed the extra braces :-/

Maarten.

On Wed, 2003-04-02 at 11:34, Olly Betts wrote:
> On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > >         >           {
> > >         >             std::string s;
> > >         >             s += '0';
> > >         >           }
> > >         >           exit(0);
> 
> > Just out of curiosity, why would s be destructed if you call exit()?
> 
> s is destructed at the end of the block where it's defined - i.e. the
> line before exit is called.
> 
> Cheers,
>     Olly
> 

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

[Olly B. <ol...@su...>]

On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> >         >           {
> >         >             std::string s;
> >         >             s += '0';
> >         >           }
> >         >           exit(0);

> Just out of curiosity, why would s be destructed if you call exit()?

s is destructed at the end of the block where it's defined - i.e. the
line before exit is called.

Cheers,
    Olly

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

[Maarten B. <maa...@mi...>]

Hello,

Just out of curiosity, why would s be destructed if you call exit()?
I find it somewhat hard to believe (counter intuitive, even unwanted)
that calling exit() from inside maybe a 10 level deep calling sequence
would cause all stack based variables to be destructed?

Thanks for any insights!

Cheers,

Maarten.


On Tue, 2003-04-01 at 23:36, Geoff Alexander wrote:
>  
>         ----- Original Message ----- 
>         From: Jeremy Fitzhardinge
>         To: Geoff Alexander
>         Cc: val...@li...
>         Sent: Tuesday, April 01, 2003 1:31 AM
>         Subject: Re: [Valgrind-users] "still reachable" memory from
>         g++'sstd::string
>                 On Mon, 2003-03-31 at 20:47, Geoff Alexander wrote: 
>         > In running valgrind 1.0.4 against a small program of mine,
>         > valgrind reports "still reachable" memory at exit, both with
>         > g++ 2.95.2 and gcc 3.2 on SuSE Linux x86 7.1.  I've tracked
>         > the problem down to std::string.  Here's a small program
>         > that illustrates the problem: 
>         >         #include <cstdlib>
>         >         #include <string>
>         >         int main(int argc, char* argv[])
>         >         {
>         >           {
>         >             std::string s;
>         >             s += '0';
>         >           }
>         >           exit(0);
>         >         } 
>         
>         What happens if you return 0 rather than exit(0)?  I'm not
>         sure that s will necessarily have been destructed if you use
>         exit. 
>                 J 
> Thanks for the suggestion.  Using return 0 rather than exit(0) didn't
> change anything.  I verified under gdb that s is being destructed in
> both cases.
>  
> Geoff Alexander
-- 
Maarten Ballintijn <maa...@mi...>
Massachusetts Institute of Technology

Re: [Valgrind-users] "still reachable" memory from g++'s std::string

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

----- Original Message -----=20
From: "Nicholas Nethercote" <nj...@ca...>
To: "Geoff Alexander" <gal...@nc...>
Cc: <val...@li...>
Sent: Tuesday, April 01, 2003 5:08 AM
Subject: Re: [Valgrind-users] "still reachable" memory from g++'s =
std::string


> On Mon, 31 Mar 2003, Geoff Alexander wrote:
>=20
> > In running valgrind 1.0.4 against a small program of mine, valgrind =
reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc =
3.2 on SuSE Linux x86 7.1.  I've tracked the problem down to =
std::string.  Here's a small program that illustrates the problem:
> >   #include <cstdlib>
> >   #include <string>
> >   int main(int argc, char* argv[])
> >   {
> >     {
> >       std::string s;
> >       s +=3D '0';
> >     }
> >     exit(0);
> >   }
> > Under g++ 2.95.2, valgrind reports:
> >   =3D=3D1214=3D=3D LEAK SUMMARY:
> >   =3D=3D1214=3D=3D definitely lost: 0 bytes in 0 blocks.
> >   =3D=3D1214=3D=3D possibly lost: 0 bytes in 0 blocks.
> >   =3D=3D1214=3D=3D still reachable: 1280 bytes in 1 blocks.
> > and under g++ 3.2, valgrind reports:
> >   =3D=3D1236=3D=3D LEAK SUMMARY:
> >   =3D=3D1236=3D=3D definitely lost: 0 bytes in 0 blocks.
> >   =3D=3D1236=3D=3D possibly lost: 0 bytes in 0 blocks.
> >   =3D=3D1236=3D=3D still reachable: 640 bytes in 1 blocks.
> >
> > Note that the amount of memory report as "still reachable" grows =
larger
> > as more characters are appended to s.  I suspect that the "still
> > reachable" memory is a static buffer allocated in std::string, =
rather
> > than leaked memory.  Is this correct?  If so, is there way to tell
> > valgrind not to report the memory allocated this std::string static
> > buffer.
>=20
> It shouldn't be static -- the leak checker only considers dynamically
> allocated blocks.
>=20
> It sounds pretty harmless, if you want to suppress it, download v1.9.4 =
and
> use the "Leak" suppression type (1.0.4 doesn't support it).  Ignore =
what
> it says about 1.9.4 being "development" -- it's more stable and =
generally
> better than 1.0.4.  Note that you have to write the suppression type =
as
> "Memcheck:Leak" for 1.9.4, see the supplied .supp files for examples.
> Also note that when writing suppressions you have to give the =
_mangled_
> name for C++ functions -- use the --demangle=3Dno option to Valgrind =
to find
> them out.
>=20
> HTH.
>=20
> N
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:=20
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
> 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

Thanks for the suggestions.  I realize the leak checker only considers =
dynamically allocated blocks.  What I meant by "static buffer" is that =
the address of the dynamically allocated block is being saved in a =
static variable (really a misuse of the term "static buffer") and not =
being freed when s is destructed.  I investigated this further, and =
indeed this is the case.  In both g++ 2.95.2 and g++ 3.2, the allocated =
memory is being saved in the
  static char* _S_start_free
member of
  template <bool threads, int inst> class __default_alloc_template
which is defined in stl_alloc.h (g++ 2.95.2) or bits/stl_alloc.h (g++ =
3.2).  So, it seems that the "leaked" memory is allocated as part of =
gcc's STL memory management.  I was able to suppress the leak using =
valgrind 1.9.4.  For g++ 2.95.2, my suppression file is
  #-------- For g++ 2.95.2
  {
    malloc/__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned =
int, int &)
    Memcheck:Leak
    fun:malloc
    fun:_S_chunk_alloc__t24__default_alloc_template2b1i0UiRi
  }
and for g++ 3.2, my suppression file is
  #-------- For g++ 3.2
  {
    __builtin_new/operator =
new(unsigned)/std::__default_alloc_template<true, =
0>::_S_chunk_alloc(unsigned, int&)
    Memcheck:Leak
    fun:__builtin_new
    fun:_Znwj
    fun:_ZNSt24__default_alloc_templateILb1ELi0EE14_S_chunk_allocEjRi
  }
Thanks again for your help.

Geoff Alexander

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

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

  ----- Original Message -----=20
  From: Jeremy Fitzhardinge=20
  To: Geoff Alexander=20
  Cc: val...@li...=20
  Sent: Tuesday, April 01, 2003 1:31 AM
  Subject: Re: [Valgrind-users] "still reachable" memory from =
g++'sstd::string
    On Mon, 2003-03-31 at 20:47, Geoff Alexander wrote:=20
    In running valgrind 1.0.4 against a small program of mine, valgrind =
reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc =
3.2 on SuSE Linux x86 7.1.  I've tracked the problem down to =
std::string.  Here's a small program that illustrates the problem:=20
      #include <cstdlib>
      #include <string>
      int main(int argc, char* argv[])
      {
        {
          std::string s;
          s +=3D '0';
        }
        exit(0);
      }=20

  What happens if you return 0 rather than exit(0)?  I'm not sure that s =
will necessarily have been destructed if you use exit.=20
    J=20
Thanks for the suggestion.  Using return 0 rather than exit(0) didn't =
change anything.  I verified under gdb that s is being destructed in =
both cases.

Geoff Alexander

Re: [Valgrind-users] Port to ia-64 possible ?

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

In the longer run it would be nice to completely redesign the 
virtual CPU stuff, so that multiple architectures could be
supported.  The compiler technology for that kind of thing is
well established.  However, doing so would require substantial
hacking input over a sustained period of time, and is not
something that anyone can viably do in their spare time.

So the prospects are not good.

J


On Tuesday 01 April 2003 10:17 pm, Nicholas Nethercote wrote:
> On Tue, 1 Apr 2003, Markus Bernhardt wrote:
> > Is there a chance valgrind will be ported to the upcoming
> > ia-64 (Intel Itanium) architecture ?
>
> I wouldn't count on it, sorry.
>
> 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] Port to ia-64 possible ?

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

On Tue, 1 Apr 2003, Markus Bernhardt wrote:

> Is there a chance valgrind will be ported to the upcoming
> ia-64 (Intel Itanium) architecture ?

I wouldn't count on it, sorry.

N

[Valgrind-users] Port to ia-64 possible ?

[Markus B. <Mar...@sc...>]

First I like to say a big thank you to the authors and contributors
of valgrind for this superb tool. It saved my life more than once.

Is there a chance valgrind will be ported to the upcoming 
ia-64 (Intel Itanium) architecture ?

I'm so used to develop with valgrind, it really hurts not having it.
(You'll always recognize the worth of a tool if you don't have it any more)

- markus

Re: [Valgrind-users] "still reachable" memory from g++'s std::string

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

On Mon, 31 Mar 2003, Geoff Alexander wrote:

> In running valgrind 1.0.4 against a small program of mine, valgrind reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc 3.2 on SuSE Linux x86 7.1.  I've tracked the problem down to std::string.  Here's a small program that illustrates the problem:
>   #include <cstdlib>
>   #include <string>
>   int main(int argc, char* argv[])
>   {
>     {
>       std::string s;
>       s += '0';
>     }
>     exit(0);
>   }
> Under g++ 2.95.2, valgrind reports:
>   ==1214== LEAK SUMMARY:
>   ==1214== definitely lost: 0 bytes in 0 blocks.
>   ==1214== possibly lost: 0 bytes in 0 blocks.
>   ==1214== still reachable: 1280 bytes in 1 blocks.
> and under g++ 3.2, valgrind reports:
>   ==1236== LEAK SUMMARY:
>   ==1236== definitely lost: 0 bytes in 0 blocks.
>   ==1236== possibly lost: 0 bytes in 0 blocks.
>   ==1236== still reachable: 640 bytes in 1 blocks.
>
> Note that the amount of memory report as "still reachable" grows larger
> as more characters are appended to s.  I suspect that the "still
> reachable" memory is a static buffer allocated in std::string, rather
> than leaked memory.  Is this correct?  If so, is there way to tell
> valgrind not to report the memory allocated this std::string static
> buffer.

It shouldn't be static -- the leak checker only considers dynamically
allocated blocks.

It sounds pretty harmless, if you want to suppress it, download v1.9.4 and
use the "Leak" suppression type (1.0.4 doesn't support it).  Ignore what
it says about 1.9.4 being "development" -- it's more stable and generally
better than 1.0.4.  Note that you have to write the suppression type as
"Memcheck:Leak" for 1.9.4, see the supplied .supp files for examples.
Also note that when writing suppressions you have to give the _mangled_
name for C++ functions -- use the --demangle=no option to Valgrind to find
them out.

HTH.

N

Re: [Valgrind-users] "still reachable" memory from g++'s std::string

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

        On Mon, 2003-03-31 at 20:47, Geoff Alexander wrote:
        
> In running valgrind 1.0.4 against a small program of mine,
> valgrind reports "still reachable" memory at exit, both with g++
> 2.95.2 and gcc 3.2 on SuSE Linux x86 7.1.  I've tracked the problem
> down to std::string.  Here's a small program that illustrates the
> problem:
> 
>         #include <cstdlib>
>         #include <string>
>         int main(int argc, char* argv[])
>         {
>           {
>             std::string s;
>             s += '0';
>           }
>           exit(0);
>         }


What happens if you return 0 rather than exit(0)?  I'm not sure that s
will necessarily have been destructed if you use exit.

        J

[Valgrind-users] "still reachable" memory from g++'s std::string

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

In running valgrind 1.0.4 against a small program of mine, valgrind =
reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc =
3.2 on SuSE Linux x86 7.1.  I've tracked the problem down to =
std::string.  Here's a small program that illustrates the problem:
  #include <cstdlib>
  #include <string>
  int main(int argc, char* argv[])
  {
    {
      std::string s;
      s +=3D '0';
    }
    exit(0);
  }
Under g++ 2.95.2, valgrind reports:
  =3D=3D1214=3D=3D LEAK SUMMARY:
  =3D=3D1214=3D=3D definitely lost: 0 bytes in 0 blocks.
  =3D=3D1214=3D=3D possibly lost: 0 bytes in 0 blocks.
  =3D=3D1214=3D=3D still reachable: 1280 bytes in 1 blocks.
and under g++ 3.2, valgrind reports:
  =3D=3D1236=3D=3D LEAK SUMMARY:
  =3D=3D1236=3D=3D definitely lost: 0 bytes in 0 blocks.
  =3D=3D1236=3D=3D possibly lost: 0 bytes in 0 blocks.
  =3D=3D1236=3D=3D still reachable: 640 bytes in 1 blocks.
Note that the amount of memory report as "still reachable" grows larger =
as more characters are appended to s.  I suspect that the "still =
reachable" memory is a static buffer allocated in std::string, rather =
than leaked memory.  Is this correct?  If so, is there way to tell =
valgrind not to report the memory allocated this std::string static =
buffer.=20

Thanks,
Geoff Alexander

Re: [Valgrind-developers] Re: [Valgrind-users] Need testers for MMX support

[Arnaud D. <arn...@ge...>]

Hi,

That's all excellent news. Another small self-contained code is
Wolfgang Suttrop's data acquisition benchmark
(http://www.ipp.mpg.de/~Wolfgang.Suttrop/daq/dabench/)
It builds easily and triggers a valgrind fault:

<quote>
disInstr: unhandled 2-byte opcode: 0x71 0xF0 0x4
This _might_ be the result of executing a SSE, SSE2 or 3DNow!
instruction.  Valgrind does not currently support such instructions.  Sorry.
</quote>

I haven't found that many freely available codes that use MMX
instructions except within large libraries such as gmp. However,
using gcc 3.2's "mmintrin.h", it shouldn't be too difficult to write
some test cases.

Regards,


----- Original Message -----
From: "Julian Seward" <js...@ac...>
To: "Arnaud Desitter" <arn...@ge...>;
<val...@li...>
Sent: Sunday, March 30, 2003 12:31 PM
Subject: Re: [Valgrind-developers] Re: [Valgrind-users] Need testers for MMX
support


>
> Yes, irred was a good test case, and shook out various bugs and
> missing insns.  I now believe the head should run most MMX code OK,
> and I've taught the memcheck (default) skin how to instrument MMX
> code, so "valgrind ./my_mmx_program" should work.
>
> J
>
> On Thursday 27 March 2003 11:59 am, Arnaud Desitter wrote:
> > Hi,
> >
> > I do not have much time as the moment to test it myself
> > but Richard Brent's irred should be a good test case, small
> > and simple.
> > http://web.comlab.ox.ac.uk/oucl/work/richard.brent/irred.html
> >
> > Regards,
> >

Re: [Valgrind-users] Using valgrind from a test suite

[Olly B. <ol...@su...>]

On Mon, Mar 31, 2003 at 08:49:56AM +0100, Nicholas Nethercote wrote:
> On Mon, 31 Mar 2003, Olly Betts wrote:
> 
> > A third possibility I've just thought of is to use:
> >
> > valgrind --logfile-fd=-1 /dev/null [program and args]
> >
> > (Or redirect to a particular fd and direct that to /dev/null but then
> > that fd might be used by something - -1 is nice as it always works...)
> 
> That seems a good way to do it, since it doesn't require any changes.
> 
> Is -1 the file descriptor for /dev/null, or is it just an invalid file
> descriptor and thus the output goes nowhere?

It's invalid.

> I just tried it, you don't need to write /dev/null in the command line as
> you have above.

Sorry yes.  I originally had "--logfile-fd=3 3> /dev/null" and
apparently failed to edit out the "/dev/null" as well as the "3>"
when I realised -1 would be a better option.  To be clear:

valgrind --logfile-fd=-1 [program and args]

Cheers,
    Olly

Re: [Valgrind-users] Using valgrind from a test suite

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

On Mon, 31 Mar 2003, Olly Betts wrote:

> A third possibility I've just thought of is to use:
>
> valgrind --logfile-fd=-1 /dev/null [program and args]
>
> (Or redirect to a particular fd and direct that to /dev/null but then
> that fd might be used by something - -1 is nice as it always works...)

That seems a good way to do it, since it doesn't require any changes.

Is -1 the file descriptor for /dev/null, or is it just an invalid file
descriptor and thus the output goes nowhere?

I just tried it, you don't need to write /dev/null in the command line as
you have above.

N

Re: [Valgrind-users] Using valgrind from a test suite

[Olly B. <ol...@su...>]

On Sat, Mar 29, 2003 at 10:19:18PM +0000, Nicholas Nethercote wrote:
> On Fri, 28 Mar 2003, Olly Betts wrote:
> 
> > > >   int VALGRIND_SILENT(int silent);
> > > >
> > > >     If silent is non-zero, suppress *all* output from valgrind.  Returns
> > > >     the setting prior to the call.
> 
> I think a command line option is more appropriate for this.  Currently
> -q turns off all normal output, but still prints errors.  Using -q -q
> could suppress everything.  Although this would be useless without using
> the following client requests, so maybe a client request is a good way to
> do it.

I did consider a command line option, but went for the client request
for that reason.

A third possibility I've just thought of is to use:

valgrind --logfile-fd=-1 /dev/null [program and args]

(Or redirect to a particular fd and direct that to /dev/null but then
that fd might be used by something - -1 is nice as it always works...)

If this is the preferred approach perhaps it should be documented that
"--logfile-fd=-1" will suppress messages to avoid worries that a future
valgrind might check the supplied fd is writable...

For my purposes, VALGRIND_SILENT certainly isn't vital.

> All in all, they're pretty minor changes, and I think it's a good thing to
> make it easier to incorporate Valgrind into regression testing.  So I'd be
> happy to add them, but only once I've done my core/skin reshuffle
> (assuming it is completed), which will take a little while.

Cool.

Cheers,
    Olly

Re: [Valgrind-developers] Re: [Valgrind-users] Need testers for MMX support

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

Yes, irred was a good test case, and shook out various bugs and
missing insns.  I now believe the head should run most MMX code OK,
and I've taught the memcheck (default) skin how to instrument MMX
code, so "valgrind ./my_mmx_program" should work.

J

On Thursday 27 March 2003 11:59 am, Arnaud Desitter wrote:
> Hi,
>
> I do not have much time as the moment to test it myself
> but Richard Brent's irred should be a good test case, small
> and simple.
> http://web.comlab.ox.ac.uk/oucl/work/richard.brent/irred.html
>
> Regards,
>
> ----- Original Message -----
> From: "Julian Seward" <js...@ac...>
> To: <val...@li...>;
> <val...@li...>
> Cc: <os...@kd...>
> Sent: Wednesday, March 26, 2003 9:30 PM
> Subject: [Valgrind-users] Need testers for MMX support
>
> > Greetings, y'all.
> >
> > I just committed to the cvs head, initial support for MMX instructions.
> > Just MMX, not SSE or SSE2.  SSE and SSE2 are for later; a staged approach
> > keeps the resulting code simpler and more maintainable (I hope).
> >
> > Most MMX instructions now work.  What would be very useful is for
> > people who have apps with MMX instructions, to check out and build the
> > head [details below] and then run their MMXish apps on it.  There will
> > be initial breakage, but the sooner this is done, the sooner we will
> > have working MMX support :-)
> >
> > So, can anyone help out?
> >
> > If this all works out satisfactorily, I will seriously consider
>
> backporting
>
> > it to the stable branch (the >= 1.9.4 series).
> >
> > J
> >
> >
> > Building from anon cvs:
> > You need autoconf >= 1.5.  Apart from that it should be easy.
> >
> > Here's how:
> >
> > cvs -d:pserver:ano...@cv...:/cvsroot/valgrind
>
> login
>
> > When prompted for a password for anonymous, simply press the Enter key.
>
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind
>
> >           co valgrind
> >
> > cd valgrind
> > ./autogen.sh
> > ./configure --prefix=....
> > make
> > make install
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] valgrind-1.9.4.tar.bz2

[Tom H. <th...@cy...>]

In message <Pine.GSO.4.44.0303300122090.20557-100000@apollo>
          Kieun Kim <ki...@ec...> wrote:

>  I would like to install valgrind, but I do not know how to uncompress
> this.

You need bunzip2 - see http://sources.redhat.com/bzip2/ for details.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

[Valgrind-users] valgrind-1.9.4.tar.bz2

[Kieun K. <ki...@ec...>]

Hi,

 I would like to install valgrind, but I do not know how to uncompress
this.

 Please let me know how to do this.

 Thanks,

Kieun K.

Re: [Valgrind-users] Using valgrind from a test suite

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

On Fri, 28 Mar 2003, Olly Betts wrote:

> > >   int VALGRIND_SILENT(int silent);
> > >
> > >     If silent is non-zero, suppress *all* output from valgrind.  Returns
> > >     the setting prior to the call.

I think a command line option is more appropriate for this.  Currently
-q turns off all normal output, but still prints errors.  Using -q -q
could suppress everything.  Although this would be useless without using
the following client requests, so maybe a client request is a good way to
do it.


> > >   VALGRIND_READ_COUNTERS(int *errors, int *lost, int *possiblylost,
> > > 			 int *reachable);
> > >
> > >     Read counters into pointed to variables.  A pointer can be zero if
> > >     you aren't interested in a particular value.
> > >
> > >   VALGRIND_RESET_COUNTERS
> > >
> > >     Zeros error and leak counters.

The variable for counting the number of errors is a static global variable
in coregrind/vg_errcontext.c, called "vg_n_errs_found".  And the variables
for "lost", "possiblylost"  and "reachable" are local variables within the
function VG_(generic_detect_memory_leaks)() in coregrind/vg_memory.c.

The local variables would have to be made into static ones, and then get()
and reset() functions would be needed for the four variables which the
client requests would call.  This isn't much of a problem, I guess.

Also, some reshuffling of the core/skin split I'm doing is likely to make
it necessary to split VALGRIND_READ_COUNTERS into two, since the number of
errors will be a core thing, but the leak counts will be a
Memcheck/Addrcheck skin thing.  But that doesn't matter so much.

All in all, they're pretty minor changes, and I think it's a good thing to
make it easier to incorporate Valgrind into regression testing.  So I'd be
happy to add them, but only once I've done my core/skin reshuffle
(assuming it is completed), which will take a little while.

N

Re: [Valgrind-users] Do you already have a --tidoffset parameter?

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

On Fri, 2003-03-28 at 10:43, Peter H Smith wrote:

> When I run a program under valgrind, pthread_self() will
> return a number between 1 and 50.  This doesn't catch
> some latent errors. 

I've been thinking about ORing in something into the top of thread IDs
as seen by the client code so that skins (like helgrind) can more easily
find thread IDs when scanning memory.  I would have the side effect of
breaking any program which thinks that pthread_t is just a small
integer.


        J

Re: [Valgrind-users] Do you already have a --tidoffset parameter?

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

Hi,

On Fri, Mar 28, 2003 at 01:43:16PM -0500, Peter H Smith wrote:

> When I run a program under valgrind, pthread_self() will return a number
> between 1 and 50.  This doesn't catch some latent errors.  Consider this
> simplification of some bone-headed trace code:
 
> #define PENNY_WISE 5
> char header[PENNY_WISE];
> sprintf(header, "%d: ", pthread_self());
> fprintf(stderr, "%s%s\n", header, message);
 
> There is a latent buffer overrun here that won't be tripped under Valgrind
> because thread ids are always small.  I'd like to be able to set the base
> thread id to something like 0x800000000 or 0xFFFF0000 and test to be sure
> this buffer nonsense is not a problem.

While configurability might be a nice thing in general, this might be too
much. I have never seen code like the one you gave as example (and I have
audited quite a lot open source applications).

What might be nice in general would be to simulate a behaviour similar to
the native implementation. I.e. if libpthread gives high TID's, then
valgrind should, too. But as I have never dabbled with this features of
valgrind, this might be off the road, though.

Also, the program might also just misbehave on small TID's and behave
correctly at large TID's. Or produce a buffer overflow at small TID's. Or
negative ones. Etc. That quickly leads to "fuzzing" the application with
random data that might produce faults.


One can use other examples such as "malloc(0)", which I have seen in real
code to produce process-wide unique-id's. Valgrind or any other malloc
implementation might change this and return a constant (as zero bytes can
never be used), hence break the program. Or they do not. The point is, if
programs are broken without valgrind, valgrind should not try to produce
specific bordercases that might cause trouble.

(My point of view, but maybe the valgrind developers can support/nullify my
 points ;-)


> Peter H. Smith
> Advisory Software Engineer
> xSeries Systems Management
> IBM Server Group

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] Do you already have a --tidoffset parameter?

[Peter H S. <smi...@us...>]

When I run a program under valgrind, pthread_self() will
return a number between 1 and 50.  This doesn't catch
some latent errors.  Consider this simplification of
some bone-headed trace code:

#define PENNY_WISE 5
char header[PENNY_WISE];
sprintf(header, "%d: ", pthread_self());
fprintf(stderr, "%s%s\n", header, message);

There is a latent buffer overrun here that won't be tripped
under Valgrind because thread ids are always small.
I'd like to be able to set the base thread id to something
like 0x800000000 or 0xFFFF0000 and test to be sure
this buffer nonsense is not a problem.

I suppose it's harder, but it would also be nice to be able
to put a "translation layer" between getpid() and kill(), etc
so that you could force pids to be large too.  At least make
getpid() return a configurable value like 0x80000000 or
0xF0000000, and have kill() turn it back to the right value
before passing it on.  Ideally translate any returned pid to
have some minimum value, and translate the returned pids
to real pids on the way out.  This wouldn't be perfect but
would be useful in stoopid programs.

I suppose I should get over "code approach anxiety" and
add it myself, but I'm too busy finding bone-headed buffer
overflows to put it in right now...

Peter H. Smith
Advisory Software Engineer
xSeries Systems Management
IBM Server Group
Phone (919) 543-6140 (T/L 441-6140)
email: smi...@us...

Re: [Valgrind-users] Using valgrind from a test suite

[Olly B. <ol...@su...>]

On Fri, Mar 28, 2003 at 12:20:44AM +0000, Nicholas Nethercote wrote:
> On Wed, 26 Mar 2003, Olly Betts wrote:
> 
> > I had a brief discussion with Julian back in April 2002 about using
> > valgrind as part of an automated testsuite for a library.
> 
> > My idea was to add a call or two so that the testsuite could be run
> > under valgrind and the test harness could find out about problems
> > from valgrind and fail the test in question.
> 
> > The testsuite needs to be able to test if memory has been leaked (so it
> > can fail that test) and it would be useful to be able to totally
> > suppress valgrind's output for that check when running in the
> > testsuite's terse mode - it would just print "test7: FAIL (MEMORY LEAK)"
> > or something similar.
> >
> > And if a test has failed with a memory leak or valgrind error, we want
> > to be able to reset valgrind's counters so we can move onto the next
> > test and not have the same problem re-reported.
> 
> >   int VALGRIND_SILENT(int silent);
> >
> >     If silent is non-zero, suppress *all* output from valgrind.  Returns
> >     the setting prior to the call.
> >
> >   VALGRIND_READ_COUNTERS(int *errors, int *lost, int *possiblylost,
> > 			 int *reachable);
> >
> >     Read counters into pointed to variables.  A pointer can be zero if
> >     you aren't interested in a particular value.
> >
> >   VALGRIND_RESET_COUNTERS
> >
> >     Zeros error and leak counters.
> 
> I don't entirely understand what you want to do.

Sorry, I'll try to elaborate.  Let me know if anything is still not
clear...
 
> Does your entire test suite run as a single process under a single
> invocation of Valgrind?  If so do you use --trace-children for the
> individual tests?

No, the testsuite consists of over 300 tests, grouped into 3 programs.
Each test is a function.  Putting each test in a separate program isn't
feasible - when static linking is in use it would inflate the disk space
requirements to a ludicrous extent.

We could potentially run each test program many times, running one test
function each time.

> I assume your three functions are client requests...  would they be
> inserted into your test harness program, or the test programs themselves?

The test harness is linked into each test program, and calls the test
functions one after another, reporting any which fail (or are skipped
if they can't be run for some reason).  The test harness will also
catch unexpected exceptions and signals.

The 3 client requests would be used in that test harness.

> I guess you want to do something like: run valgrind in silent mode, after
> each test read the counters to see if any leaks occurred and if so print
> out the "terse" failure message, then reset them before going onto the
> next test.

Indeed.  And if the testsuite was run in "verbose" mode (which you
generally use with it running just one test function) it wouldn't put
valgrind into silent mode.

> I would have thought it better for your test harness to run each test
> program under Valgrind separately, maybe using --quiet (although leak
> reports still get printed), and then maybe parse the output to see if any
> leaks occurred.  Then counters wouldn't need to be reset at all.  But
> maybe I'm missing something about what you want to do.

That would require us to run the test program once for each test
function.  Doable, but it feels rather clumsy.  I also worry about the
speed - just running the test programs under valgrind is an excuse for
a teabreak.  If we rerun under valgrind for each testcase that'll incur
valgrind retranslating the common code (test harness and library) 300+
extra times...

Cheers,
    Olly

Re: [Valgrind-users] Using valgrind from a test suite

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

On Wed, 26 Mar 2003, Olly Betts wrote:

> I had a brief discussion with Julian back in April 2002 about using
> valgrind as part of an automated testsuite for a library.

> My idea was to add a call or two so that the testsuite could be run
> under valgrind and the test harness could find out about problems
> from valgrind and fail the test in question.

> The testsuite needs to be able to test if memory has been leaked (so it
> can fail that test) and it would be useful to be able to totally
> suppress valgrind's output for that check when running in the
> testsuite's terse mode - it would just print "test7: FAIL (MEMORY LEAK)"
> or something similar.
>
> And if a test has failed with a memory leak or valgrind error, we want
> to be able to reset valgrind's counters so we can move onto the next
> test and not have the same problem re-reported.

>   int VALGRIND_SILENT(int silent);
>
>     If silent is non-zero, suppress *all* output from valgrind.  Returns
>     the setting prior to the call.
>
>   VALGRIND_READ_COUNTERS(int *errors, int *lost, int *possiblylost,
> 			 int *reachable);
>
>     Read counters into pointed to variables.  A pointer can be zero if
>     you aren't interested in a particular value.
>
>   VALGRIND_RESET_COUNTERS
>
>     Zeros error and leak counters.

I don't entirely understand what you want to do.

Does your entire test suite run as a single process under a single
invocation of Valgrind?  If so do you use --trace-children for the
individual tests?

I assume your three functions are client requests...  would they be
inserted into your test harness program, or the test programs themselves?

I guess you want to do something like: run valgrind in silent mode, after
each test read the counters to see if any leaks occurred and if so print
out the "terse" failure message, then reset them before going onto the
next test.

I would have thought it better for your test harness to run each test
program under Valgrind separately, maybe using --quiet (although leak
reports still get printed), and then maybe parse the output to see if any
leaks occurred.  Then counters wouldn't need to be reset at all.  But
maybe I'm missing something about what you want to do.

N

Re: [Valgrind-users] RH9 and valgrind (vgPlain_do_useseg assertion fail)

[Tom H. <th...@cy...>]

In message <Pin...@ye...>
          Nicholas Nethercote <nj...@ca...> wrote:

> Jeff Johnson of Red Hat wrote a patch for this and sent it to me a month
> ago.  The patch is 6,841 lines long... so maybe it's harder than you'd
> expect.  The patch did some stuff with the debuginfo package too, I don't
> know how much of it was for that.

Well the immediate cause of that failure appears to be the use of
the GDT instead of the LDT to hold thread local data, and I believe
that should be easy to fix - it just needs the set_thread_area system
call to be handled in the same way that modify_ldt currently is, and
future GDT based references to be resolved via the current thread's
local data area as set with the set_thread_area call.

Of course there may be other NPTL related issues that would appear
once that was fixed.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/