valgrind-users — General discussion list for Valgrind users

[Valgrind-users] unable to build rpm from valgrind-1.0.4 on RedHat 8.0

[Brian W. <bri...@av...>]

Hello all,
I have downloaded valgrind-1.0.4 on a RedHat 8.0 with a 2.4.18-14smp kernel
and did the ./configure, make and make install without a problem. I then
tried to build a rpm package using the valgrind.spec file which create the
valgrind-1.0.4 using rpmbuild -ba valgrind.spec and everything looked good
until I tried to install the rpm I got the following failed dependency
error.
error: Failed dependencies:
        libc.so.6(GLIBC_PRIVATE) is needed by valgrind-1.0.4-1
I did a strings /lib/libc.so.6 |grep -i private and it did return
GLIBC_PRIVATE.
Has anyone got this to work?

Brian S. Wince 
Sr. Unix/Linux Administrator 
Information Technology
AltaVista
bri...@av... 
650.320.6485 

 

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

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

On Wed, Apr 02, 2003 at 09:49:46AM -0800, Jeremy Fitzhardinge wrote:
> On Wed, 2003-04-02 at 08: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.
> 
> Do you mean the compiler is treating exit specially?

No.  Look at the code.  s is destructed at the end of the block it is
defined in.  That's how C++ works.  What happens after the block is
irrelevant to that destruction.

> Is that because
> its a noreturn function?  That still can't be right: if it were a
> noreturn function which takes a std::string argument, then it would be
> wrong to destruct the string before passing it.

But it couldn't take s as an argument, as s isn't in scope at that
point!

Cheers,
    Olly

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

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

On Wed, 2003-04-02 at 09:10, Maarten Ballintijn wrote:

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

Oh, yeah.  Mass silliness.

        J

Re: [Valgrind-users] valgrind and poll()

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

On Wed, 2003-04-02 at 09:02, David Eriksson wrote:

> For the fun of it, I tried to send a SIGHUP to my process. There is
> singal handler installed with signal() for SIGHUP, which gets executed
> properly. What also happens is that all threads (one for each connection
> that have been made to the server) get to run!
> 
> Do you have any ideas?
> 
> I will happily provide any more information that may be of interest.

What does strace have to say about your running process?  Is it blocked
in a a system call, or does it seem to be spinning away happily?

It's possible that the libc poll (or some other blocking system call) is
somehow getting called without being intercepted by Valgrind.

        J

Re: [Valgrind-users] valgrind and poll()

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

On Wed, 2003-04-02 at 09:41, Jeff Johnson wrote:

> FYI: You're running a NPTL capable library with a NPTL deprived kernel.
> 
> Meanwhile, prefix your valgrind command with
> 	LD_ASSUME_KERNEL=2.2.5 valgrind ...
> to force use of Good Old libpthread.

Are you sure?  There's only one libpthread in that glibc package; can
the one library do both NPTL and linuxthreads?

        J

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

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

On Wed, 2003-04-02 at 08: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.

Do you mean the compiler is treating exit specially?  Is that because
its a noreturn function?  That still can't be right: if it were a
noreturn function which takes a std::string argument, then it would be
wrong to destruct the string before passing it.

    J

Re: [Valgrind-users] valgrind and poll()

[Jeff J. <jb...@re...>]

On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote:
> Hello,
> 
> First, the obligatory credits: Thank you very much for writing valgrind!
> 
> When I recently subscribed to this mailing list I read a message from
> Nicholas Nethercote where he said that 1.9.4 was more stable and worked
> better than 1.0.4 so I thought I'd give it a try.
> 
> However, it seems to me like something has changed between the two
> versions, maybe regarding the combination threads and sockets.
> 
> I am running RedHat 8.0, with the latest updates installed:
> 
>   kernel-2.4.18-27.8.0
>   glibc-2.3.2-4.80
>   gcc-3.2-7
> 
> The application I'm examining with valgrind is a threaded server
> application written in C that uses glib. It is quite large and
> complicated to install, so there is no point in providing it.
> 
> I have tried to make a scaled-down example to reproduce my problem. It
> is not finished yet, but I thought that I'll try to describe the problem
> in case anyone has any suggestions:
> 
> The server creates a unix socket and makes glib poll() the socket for
> events. A client connects to the server, which accept() the connection
> and creates a new thread for handling the connection.
> 
> By using simple "printf debugging" it seems like the the new thread
> never gets scheduled to run in valgrind 1.9.4.
> 
> For the fun of it, I tried to send a SIGHUP to my process. There is
> singal handler installed with signal() for SIGHUP, which gets executed
> properly. What also happens is that all threads (one for each connection
> that have been made to the server) get to run!
> 
> Do you have any ideas?

FYI: You're running a NPTL capable library with a NPTL deprived kernel.

Meanwhile, prefix your valgrind command with
	LD_ASSUME_KERNEL=2.2.5 valgrind ...
to force use of Good Old libpthread.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jb...@re... (jb...@jb...)
Chapel Hill, NC

[Valgrind-users] valgrind and poll()

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

Hello,

First, the obligatory credits: Thank you very much for writing valgrind!

When I recently subscribed to this mailing list I read a message from
Nicholas Nethercote where he said that 1.9.4 was more stable and worked
better than 1.0.4 so I thought I'd give it a try.

However, it seems to me like something has changed between the two
versions, maybe regarding the combination threads and sockets.

I am running RedHat 8.0, with the latest updates installed:

  kernel-2.4.18-27.8.0
  glibc-2.3.2-4.80
  gcc-3.2-7

The application I'm examining with valgrind is a threaded server
application written in C that uses glib. It is quite large and
complicated to install, so there is no point in providing it.

I have tried to make a scaled-down example to reproduce my problem. It
is not finished yet, but I thought that I'll try to describe the problem
in case anyone has any suggestions:

The server creates a unix socket and makes glib poll() the socket for
events. A client connects to the server, which accept() the connection
and creates a new thread for handling the connection.

By using simple "printf debugging" it seems like the the new thread
never gets scheduled to run in valgrind 1.9.4.

For the fun of it, I tried to send a SIGHUP to my process. There is
singal handler installed with signal() for SIGHUP, which gets executed
properly. What also happens is that all threads (one for each connection
that have been made to the server) get to run!

Do you have any ideas?

I will happily provide any more information that may be of interest.

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

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/