valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Immediate segfault with valgrind-1.9.5 on RH7.1

[<sd...@cl...>]

Hi --

> On Mon, 28 Apr 2003, Stuart Brorson wrote:
> 
> > With great anticipation I downloaded and built valgrind-1.9.5 last
> > night.  I did a vanilla "./configure ; make ; make install".  When I
> > tried "valgrind ls -l", I got "Segmentation fault (core dumped)".
> > Rats!  When I run valgrind alone, I also get a segfault.
> 
> You mean even if you just type "valgrind"?  Weird... something must going
> wrong in Valgrind's startup shell script.
> 
> Can you try fiddling with $PREFIX/bin/valgrind, inserting some debug
> "echo" statements to work out where exactly the seg fault is happening?
> 
> N

OK, I fixed my problem.  I examined /usr/local/bin/valgrind.  It
turned out that at one  place in that script I had:

#LD_DEBUG=files
#LD_DEBUG=symbols
#export LD_DEBUG

This is how "make ; make install" created the script.  When I
uncommented "LD_DEBUG=symbols", and "export LD_DEBUG" valgrind started
working.  Yay!!!!

Now my only question is:  why did the default install procedure create
a script with this option commented out?  Or did I just not RTFM?

Stuart

Re: [Valgrind-users] RH8 & Glibc 2.3

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

On Monday 28 April 2003 6:25 pm, Bill Deegan wrote:
> Julian,
>
> Yes that's the problem. Multithreaded program hanging
> all threads on select statement.
>
> RH8.0 with the latest patches which include the following glibc rpm's
> glibc-2.3.2-4.80
> glibc-utils-2.3.2-4.80
> glibc-debug-2.3.2-4.80
> glibc-common-2.3.2-4.80
> glibc-debug-static-2.3.2-4.80
> glibc-profile-2.3.2-4.80
> glibc-kernheaders-2.4-7.20
> glibc-devel-2.3.2-4.80
>
> O.k. dumb question. I've checked out the code from cvs, how to
> I get configure to work?

./autogen.sh
./configure --prefix=...
make install

is what we do.  The autogen.sh seems to do all the grungy autoconf
bits; i didn't write it, but it appears to work.

J


>
> autoconf gives me:
> autoconf
> configure.in:3: error: possibly undefined macro: AM_CONFIG_HEADER
> configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
> configure.in:6: error: possibly undefined macro: AM_MAINTAINER_MODE
>
> Thanks,
> Bill
>
>
>
>
>
> From: Julian Seward <js...@ac...>
>
> >To: "William Deegan" <cab...@ho...>,
> ><val...@li...>
> >Subject: Re: [Valgrind-users] RH8 & Glibc 2.3
> >Date: Mon, 28 Apr 2003 08:44:27 +0100
> >
> > > Is there a known problem with glibc 2.3 and valgrind on redhat 8.0?
> > > Any workarounds?
> >
> >Hard to say, since you mention no specific details of any problem.
> >There is a threading problem -- some calls like accept, recv,
> >select, poll, etc, can lead to all threads being blocked rather
> >than just one.  I've fixed this in the cvs head and will backport
> >the fix to 1.9.6.  It only afflicts glibc >= 2.3.2.
> >
> >J
> >
> > > Thanks,
> > > Bill
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Valgrind-users mailing list
> >Val...@li...
> >https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail

[Valgrind-users] show-reachable option

[Antonio P. A. <ant...@er...>]

Hello.
I'm new with valgrind, and I don't know for what is the option -- show-reachable.
What is the meaning? Pointers that already point to the memory area but ... what?
This is really a memory leak?

Thanks a lot for your help!

ant

Re: [Valgrind-users] RH8 & Glibc 2.3

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

On Mon, 28 Apr 2003, Nicholas Nethercote wrote:

> Run "autogen.sh ; ./configure --prefix=wherever ; make install".  Not a
> dumb question, I don't think we say that anywhere, we should...

Ah, actually it's in the README.

N

Re: [Valgrind-users] RH8 & Glibc 2.3

[William D. <cab...@ho...>]

Julian,

Thanks!
Building now. Will let you know if this does/doesn't fix our problem.

_Bill
----- Original Message ----- 
From: "Julian Seward" <js...@ac...>
To: "Bill Deegan" <cab...@ho...>; <val...@li...>
Sent: Monday, April 28, 2003 11:16 AM
Subject: Re: [Valgrind-users] RH8 & Glibc 2.3


> On Monday 28 April 2003 6:25 pm, Bill Deegan wrote:
> > Julian,
> >
> > Yes that's the problem. Multithreaded program hanging
> > all threads on select statement.
> >
> > RH8.0 with the latest patches which include the following glibc rpm's
> > glibc-2.3.2-4.80
> > glibc-utils-2.3.2-4.80
> > glibc-debug-2.3.2-4.80
> > glibc-common-2.3.2-4.80
> > glibc-debug-static-2.3.2-4.80
> > glibc-profile-2.3.2-4.80
> > glibc-kernheaders-2.4-7.20
> > glibc-devel-2.3.2-4.80
> >
> > O.k. dumb question. I've checked out the code from cvs, how to
> > I get configure to work?
> 
> ./autogen.sh
> ./configure --prefix=...
> make install
> 
> is what we do.  The autogen.sh seems to do all the grungy autoconf
> bits; i didn't write it, but it appears to work.
> 
> J
> 
> 
> >
> > autoconf gives me:
> > autoconf
> > configure.in:3: error: possibly undefined macro: AM_CONFIG_HEADER
> > configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
> > configure.in:6: error: possibly undefined macro: AM_MAINTAINER_MODE
> >
> > Thanks,
> > Bill
> >
> >
> >
> >
> >
> > From: Julian Seward <js...@ac...>
> >
> > >To: "William Deegan" <cab...@ho...>,
> > ><val...@li...>
> > >Subject: Re: [Valgrind-users] RH8 & Glibc 2.3
> > >Date: Mon, 28 Apr 2003 08:44:27 +0100
> > >
> > > > Is there a known problem with glibc 2.3 and valgrind on redhat 8.0?
> > > > Any workarounds?
> > >
> > >Hard to say, since you mention no specific details of any problem.
> > >There is a threading problem -- some calls like accept, recv,
> > >select, poll, etc, can lead to all threads being blocked rather
> > >than just one.  I've fixed this in the cvs head and will backport
> > >the fix to 1.9.6.  It only afflicts glibc >= 2.3.2.
> > >
> > >J
> > >
> > > > Thanks,
> > > > Bill
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Val...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf
> > >_______________________________________________
> > >Valgrind-users mailing list
> > >Val...@li...
> > >https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> > _________________________________________________________________
> > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > http://join.msn.com/?page=features/junkmail
> 
> 

Re: [Valgrind-users] RH8 & Glibc 2.3

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

On Mon, 28 Apr 2003, Bill Deegan wrote:

> O.k. dumb question. I've checked out the code from cvs, how to
> I get configure to work?
>
> autoconf gives me:
> autoconf
> configure.in:3: error: possibly undefined macro: AM_CONFIG_HEADER
> configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
> configure.in:6: error: possibly undefined macro: AM_MAINTAINER_MODE

Run "autogen.sh ; ./configure --prefix=wherever ; make install".  Not a
dumb question, I don't think we say that anywhere, we should...

N

Re: [Valgrind-users] RH8 & Glibc 2.3

[Bill D. <cab...@ho...>]

Julian,

Yes that's the problem. Multithreaded program hanging
all threads on select statement.

RH8.0 with the latest patches which include the following glibc rpm's
glibc-2.3.2-4.80
glibc-utils-2.3.2-4.80
glibc-debug-2.3.2-4.80
glibc-common-2.3.2-4.80
glibc-debug-static-2.3.2-4.80
glibc-profile-2.3.2-4.80
glibc-kernheaders-2.4-7.20
glibc-devel-2.3.2-4.80

O.k. dumb question. I've checked out the code from cvs, how to
I get configure to work?

autoconf gives me:
autoconf
configure.in:3: error: possibly undefined macro: AM_CONFIG_HEADER
configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:6: error: possibly undefined macro: AM_MAINTAINER_MODE

Thanks,
Bill





>From: Julian Seward <js...@ac...>
>To: "William Deegan" <cab...@ho...>, 
><val...@li...>
>Subject: Re: [Valgrind-users] RH8 & Glibc 2.3
>Date: Mon, 28 Apr 2003 08:44:27 +0100
>
>
> > Is there a known problem with glibc 2.3 and valgrind on redhat 8.0?
> > Any workarounds?
>
>Hard to say, since you mention no specific details of any problem.
>There is a threading problem -- some calls like accept, recv,
>select, poll, etc, can lead to all threads being blocked rather
>than just one.  I've fixed this in the cvs head and will backport
>the fix to 1.9.6.  It only afflicts glibc >= 2.3.2.
>
>J
>
>
>
> >
> > Thanks,
> > Bill
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Valgrind-users] valgrind with the 2.5.x kernel

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

On Mon, 28 Apr 2003, Andr=E9s Rold=E1n wrote:

> I am the current valgrind maintainer for Debian. I will add this patch
> to the current valgrind version for Debian if you agree.

Sure, why not?  It would save some people from waiting for 1.9.6.

N

Re: [Valgrind-users] valgrind with the 2.5.x kernel

[<ar...@fl...>]

Hi

I am the current valgrind maintainer for Debian. I will add this patch
to the current valgrind version for Debian if you agree.

Thanks in advance.

Nicholas Nethercote <nj...@ca...> writes:

> On Thu, 24 Apr 2003, Jeff Sadowski wrote:
>
>> valgrind 1.9.5
>> and kernel 2.5.68
>> Is there anything spceicial I need to do in order to get it to work?
>
> Try this patch, courtesy of Anders Gustafsson on Monday :)
>
> N
>
>

-- 
Andres Roldan, CSO
Fluidsignal Group

Re: [Valgrind-users] Immediate segfault with valgrind-1.9.5 on RH7.1

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

On Mon, 28 Apr 2003, Stuart Brorson wrote:

> With great anticipation I downloaded and built valgrind-1.9.5 last
> night.  I did a vanilla "./configure ; make ; make install".  When I
> tried "valgrind ls -l", I got "Segmentation fault (core dumped)".
> Rats!  When I run valgrind alone, I also get a segfault.

You mean even if you just type "valgrind"?  Weird... something must going
wrong in Valgrind's startup shell script.

Can you try fiddling with $PREFIX/bin/valgrind, inserting some debug
"echo" statements to work out where exactly the seg fault is happening?

N

[Valgrind-users] Immediate segfault with valgrind-1.9.5 on RH7.1

[<sd...@cl...>]

Greetings --

With great anticipation I downloaded and built valgrind-1.9.5 last
night.  I did a vanilla "./configure ; make ; make install".  When I
tried "valgrind ls -l", I got "Segmentation fault (core dumped)".
Rats!  When I run valgrind alone, I also get a segfault. 

Does anybody have any suggestion about possible misconfigurations on my
system?  I am running RH7.1 with the Ximian desktop.  The kernal is
2.4.2-2.  gcc version 2.96 20000731.  glibc version 2.2.1.

My config.log file is below. 

Thanks for any and all help!

Stuart


================ config.log ===========================
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.53.  Invocation command line was

  $ ./configure 

## --------- ##
## Platform. ##
## --------- ##

hostname = Pirate
uname -m = i686
uname -r = 2.4.2-2
uname -s = Linux
uname -v = #1 Sun Apr 8 20:41:30 EDT 2001

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = i686
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/geda/bin
PATH: /usr/local/geda/bin
PATH: /sbin
PATH: /usr/sbin
PATH: /bin
PATH: /usr/bin
PATH: /usr/bin/X11
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /home/sdb/omnet/omnetpp-2.2/bin
PATH: /usr/local/Acrobat5/bin
PATH: /home/axiowave/Ixia/Ixia_3.65/ixia/bin
PATH: /usr/X11R6/bin
PATH: /usr/local/mozilla
PATH: /usr/local/Acrobat5/bin
PATH: /home/sdb/omnet/omnetpp-2.2/bin
PATH: /usr/local/Acrobat5/bin
PATH: /home/axiowave/Ixia/Ixia_3.65/ixia/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1259: checking for a BSD-compatible install
configure:1313: result: /usr/bin/install -c
configure:1324: checking whether build environment is sane
configure:1367: result: yes
configure:1400: checking for gawk
configure:1416: found /bin/gawk
configure:1426: result: gawk
configure:1436: checking whether make sets ${MAKE}
configure:1456: result: yes
configure:1602: checking whether to enable maintainer-specific portions of Makefiles
configure:1611: result: no
configure:1630: checking whether ln -s works
configure:1634: result: yes
configure:1687: checking for gcc
configure:1703: found /usr/bin/gcc
configure:1713: result: gcc
configure:1957: checking for C compiler version
configure:1960: gcc --version </dev/null >&5
2.96
configure:1963: $? = 0
configure:1965: gcc -v </dev/null >&5
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
configure:1968: $? = 0
configure:1970: gcc -V </dev/null >&5
gcc: argument to `-V' is missing
configure:1973: $? = 1
configure:1999: checking for C compiler default output
configure:2002: gcc    conftest.c  >&5
configure:2005: $? = 0
configure:2038: result: a.out
configure:2043: checking whether the C compiler works
configure:2049: ./a.out
configure:2052: $? = 0
configure:2067: result: yes
configure:2074: checking whether we are cross compiling
configure:2076: result: no
configure:2079: checking for suffix of executables
configure:2081: gcc -o conftest    conftest.c  >&5
configure:2084: $? = 0
configure:2106: result: 
configure:2112: checking for suffix of object files
configure:2136: gcc -c   conftest.c >&5
configure:2139: $? = 0
configure:2158: result: o
configure:2162: checking whether we are using the GNU C compiler
configure:2189: gcc -c   conftest.c >&5
configure:2192: $? = 0
configure:2195: test -s conftest.o
configure:2198: $? = 0
configure:2210: result: yes
configure:2216: checking whether gcc accepts -g
configure:2240: gcc -c -g  conftest.c >&5
configure:2243: $? = 0
configure:2246: test -s conftest.o
configure:2249: $? = 0
configure:2259: result: yes
configure:2286: gcc -c   conftest.c >&5
conftest.c:2: parse error before `me'
configure:2289: $? = 1
configure: failed program was:
#ifndef __cplusplus
  choke me
#endif
configure:2418: checking for style of include used by make
configure:2446: result: GNU
configure:2474: checking dependency style of gcc
configure:2536: result: gcc3
configure:2546: checking how to run the C preprocessor
configure:2572: gcc -E  conftest.c
configure:2578: $? = 0
configure:2605: gcc -E  conftest.c
configure:2601:28: ac_nonexistent.h: No such file or directory
configure:2611: $? = 1
configure: failed program was:
#line 2600 "configure"
#include "confdefs.h"
#include <ac_nonexistent.h>
configure:2648: result: gcc -E
configure:2663: gcc -E  conftest.c
configure:2669: $? = 0
configure:2696: gcc -E  conftest.c
configure:2692:28: ac_nonexistent.h: No such file or directory
configure:2702: $? = 1
configure: failed program was:
#line 2691 "configure"
#include "confdefs.h"
#include <ac_nonexistent.h>
configure:2793: checking for g++
configure:2809: found /usr/bin/g++
configure:2819: result: g++
configure:2835: checking for C++ compiler version
configure:2838: g++ --version </dev/null >&5
2.96
configure:2841: $? = 0
configure:2843: g++ -v </dev/null >&5
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
configure:2846: $? = 0
configure:2848: g++ -V </dev/null >&5
g++: argument to `-V' missing

configure:2851: $? = 1
configure:2854: checking whether we are using the GNU C++ compiler
configure:2881: g++ -c   conftest.cc >&5
configure:2884: $? = 0
configure:2887: test -s conftest.o
configure:2890: $? = 0
configure:2902: result: yes
configure:2908: checking whether g++ accepts -g
configure:2932: g++ -c -g  conftest.cc >&5
configure:2935: $? = 0
configure:2938: test -s conftest.o
configure:2941: $? = 0
configure:2951: result: yes
configure:2997: g++ -c -g -O2  conftest.cc >&5
configure:3000: $? = 0
configure:3003: test -s conftest.o
configure:3006: $? = 0
configure:3034: g++ -c -g -O2  conftest.cc >&5
configure: In function `int main ()':
configure:3026: `exit' undeclared (first use this function)
configure:3026: (Each undeclared identifier is reported only once for 
each function it appears in.)
configure:3037: $? = 1
configure: failed program was:
#line 3015 "configure"
#include "confdefs.h"

#ifdef F77_DUMMY_MAIN
#  ifdef __cplusplus
     extern "C"
#  endif
   int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
exit (42);
  ;
  return 0;
}
configure:2997: g++ -c -g -O2  conftest.cc >&5
configure:3000: $? = 0
configure:3003: test -s conftest.o
configure:3006: $? = 0
configure:3034: g++ -c -g -O2  conftest.cc >&5
configure:3037: $? = 0
configure:3040: test -s conftest.o
configure:3043: $? = 0
configure:3067: checking dependency style of g++
configure:3129: result: gcc3
configure:3175: checking for ranlib
configure:3191: found /usr/bin/ranlib
configure:3202: result: ranlib
configure:3225: checking for perl
configure:3243: found /usr/bin/perl
configure:3255: result: /usr/bin/perl
configure:3279: checking for a supported version of gcc
configure:3294: result: ok (2.96)
configure:3307: checking build system type
configure:3325: result: i686-intel-linux
configure:3335: checking host system type
configure:3349: result: i686-intel-linux
configure:3360: checking for a supported CPU
configure:3365: result: ok (i686)
configure:3378: checking for a supported OS
configure:3383: result: ok (linux)
configure:3398: checking for the kernel version
configure:3415: result: 2.4 family (2.4.2-2)
configure:3447: checking the glibc version
configure:3524: result: 2.2 family
configure:3559: checking whether sched_param has a sched_priority member
configure:3585: gcc -c   conftest.c >&5
configure:3588: $? = 0
configure:3591: test -s conftest.o
configure:3594: $? = 0
configure:3606: result: yes
configure:3616: checking whether nfds_t is defined
configure:3642: gcc -c   conftest.c >&5
configure:3645: $? = 0
configure:3648: test -s conftest.o
configure:3651: $? = 0
configure:3663: result: yes
configure:3680: checking for X
configure:3896: result: libraries /usr/X11R6/lib, headers /usr/X11R6/include
configure:3903: checking XFree version
configure:3941: result: XFree 4.x family
configure:3982: checking if this is an NPTL-based system
configure:4019: result: no
configure:4030: checking if gcc accepts -mpreferred-stack-boundary
configure:4058: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4061: $? = 0
configure:4064: test -s conftest.o
configure:4067: $? = 0
configure:4071: result: -mpreferred-stack-boundary=2
configure:4090: checking for ANSI C header files
configure:4104: gcc -E  conftest.c
configure:4110: $? = 0
configure:4195: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:4198: $? = 0
configure:4200: ./conftest
configure:4203: $? = 0
configure:4217: result: yes
configure:4241: checking for sys/types.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for sys/stat.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for stdlib.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for string.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for memory.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for strings.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for inttypes.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for stdint.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4241: checking for unistd.h
configure:4254: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4257: $? = 0
configure:4260: test -s conftest.o
configure:4263: $? = 0
configure:4273: result: yes
configure:4308: checking fcntl.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking fcntl.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for fcntl.h
configure:4395: result: yes
configure:4308: checking malloc.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking malloc.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for malloc.h
configure:4395: result: yes
configure:4299: checking for stdlib.h
configure:4304: result: yes
configure:4299: checking for string.h
configure:4304: result: yes
configure:4308: checking sys/socket.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking sys/socket.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for sys/socket.h
configure:4395: result: yes
configure:4308: checking sys/statfs.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking sys/statfs.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for sys/statfs.h
configure:4395: result: yes
configure:4308: checking sys/time.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking sys/time.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for sys/time.h
configure:4395: result: yes
configure:4308: checking termios.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking termios.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for termios.h
configure:4395: result: yes
configure:4299: checking for unistd.h
configure:4304: result: yes
configure:4308: checking utime.h usability
configure:4317: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4320: $? = 0
configure:4323: test -s conftest.o
configure:4326: $? = 0
configure:4335: result: yes
configure:4339: checking utime.h presence
configure:4346: gcc -E  conftest.c
configure:4352: $? = 0
configure:4370: result: yes
configure:4388: checking for utime.h
configure:4395: result: yes
configure:4410: checking for uid_t in sys/types.h
configure:4430: result: yes
configure:4445: checking for off_t
configure:4472: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4475: $? = 0
configure:4478: test -s conftest.o
configure:4481: $? = 0
configure:4491: result: yes
configure:4503: checking for size_t
configure:4530: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4533: $? = 0
configure:4536: test -s conftest.o
configure:4539: $? = 0
configure:4549: result: yes
configure:4561: checking whether time.h and sys/time.h may both be included
configure:4589: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:4592: $? = 0
configure:4595: test -s conftest.o
configure:4598: $? = 0
configure:4608: result: yes
configure:4620: checking for working memcmp
configure:4671: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:4674: $? = 0
configure:4676: ./conftest
configure:4679: $? = 0
configure:4692: result: yes
configure:4702: checking for stdlib.h
configure:4707: result: yes
configure:4702: checking for unistd.h
configure:4707: result: yes
configure:4815: checking for getpagesize
configure:4858: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:4861: $? = 0
configure:4864: test -s conftest
configure:4867: $? = 0
configure:4877: result: yes
configure:4887: checking for working mmap
configure:5026: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5029: $? = 0
configure:5031: ./conftest
configure:5034: $? = 0
configure:5047: result: yes
configure:5058: checking return type of signal handlers
configure:5092: gcc -c -mpreferred-stack-boundary=2  conftest.c >&5
configure:5095: $? = 0
configure:5098: test -s conftest.o
configure:5101: $? = 0
configure:5111: result: void
configure:5132: checking for floor
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
/tmp/ccYY43bc.o: In function `main':
/tmp/ccYY43bc.o(.text+0x9): undefined reference to `floor'
collect2: ld returned 1 exit status
configure:5178: $? = 1
configure: failed program was:
#line 5137 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char floor (); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
   builtin and then its argument prototype would still apply.  */
char floor ();
char (*f) ();

#ifdef F77_DUMMY_MAIN
#  ifdef __cplusplus
     extern "C"
#  endif
   int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_floor) || defined (__stub___floor)
choke me
#else
f = floor;
#endif

  ;
  return 0;
}
configure:5194: result: no
configure:5132: checking for memchr
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for memset
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5147: warning: conflicting types for built-in function `memset'
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for mkdir
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for strchr
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for strdup
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for strpbrk
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for strrchr
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5132: checking for strstr
configure:5175: gcc -o conftest -mpreferred-stack-boundary=2   conftest.c  >&5
configure:5178: $? = 0
configure:5181: test -s conftest
configure:5184: $? = 0
configure:5194: result: yes
configure:5300: creating ./config.status

## ---------------------- ##
## Running config.status. ##
## ---------------------- ##

This file was extended by config.status, which was
generated by GNU Autoconf 2.53.  Invocation command line was

  CONFIG_FILES    = 
  CONFIG_HEADERS  = 
  CONFIG_LINKS    = 
  CONFIG_COMMANDS = 
  $ ./config.status 

on Pirate

config.status:657: creating Makefile
config.status:657: creating valgrind.spec
config.status:657: creating docs/Makefile
config.status:657: creating tests/Makefile
config.status:657: creating tests/vg_regtest
config.status:657: creating tests/unused/Makefile
config.status:657: creating include/Makefile
config.status:657: creating auxprogs/Makefile
config.status:657: creating coregrind/Makefile
config.status:657: creating coregrind/demangle/Makefile
config.status:657: creating coregrind/docs/Makefile
config.status:657: creating coregrind/valgrind
config.status:657: creating addrcheck/Makefile
config.status:657: creating addrcheck/tests/Makefile
config.status:657: creating addrcheck/docs/Makefile
config.status:657: creating memcheck/Makefile
config.status:657: creating memcheck/tests/Makefile
config.status:657: creating memcheck/docs/Makefile
config.status:657: creating cachegrind/Makefile
config.status:657: creating cachegrind/tests/Makefile
config.status:657: creating cachegrind/docs/Makefile
config.status:657: creating cachegrind/cg_annotate
config.status:657: creating corecheck/Makefile
config.status:657: creating corecheck/tests/Makefile
config.status:657: creating corecheck/docs/Makefile
config.status:657: creating helgrind/Makefile
config.status:657: creating helgrind/tests/Makefile
config.status:657: creating helgrind/docs/Makefile
config.status:657: creating lackey/Makefile
config.status:657: creating lackey/tests/Makefile
config.status:657: creating lackey/docs/Makefile
config.status:657: creating none/Makefile
config.status:657: creating none/tests/Makefile
config.status:657: creating none/docs/Makefile
config.status:761: creating config.h
config.status:1043: executing depfiles commands

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-intel-linux
ac_cv_build_alias=i686-intel-linux
ac_cv_c_compiler_gnu=yes
ac_cv_cxx_compiler_gnu=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_func_floor=no
ac_cv_func_getpagesize=yes
ac_cv_func_memchr=yes
ac_cv_func_memcmp_working=yes
ac_cv_func_memset=yes
ac_cv_func_mkdir=yes
ac_cv_func_mmap_fixed_mapped=yes
ac_cv_func_strchr=yes
ac_cv_func_strdup=yes
ac_cv_func_strpbrk=yes
ac_cv_func_strrchr=yes
ac_cv_func_strstr=yes
ac_cv_have_x='have_x=yes 		ac_x_includes=/usr/X11R6/include ac_x_libraries=/usr/X11R6/lib'
ac_cv_header_fcntl_h=yes
ac_cv_header_inttypes_h=yes
ac_cv_header_malloc_h=yes
ac_cv_header_memory_h=yes
ac_cv_header_stdc=yes
ac_cv_header_stdint_h=yes
ac_cv_header_stdlib_h=yes
ac_cv_header_string_h=yes
ac_cv_header_strings_h=yes
ac_cv_header_sys_socket_h=yes
ac_cv_header_sys_stat_h=yes
ac_cv_header_sys_statfs_h=yes
ac_cv_header_sys_time_h=yes
ac_cv_header_sys_types_h=yes
ac_cv_header_termios_h=yes
ac_cv_header_time=yes
ac_cv_header_unistd_h=yes
ac_cv_header_utime_h=yes
ac_cv_host=i686-intel-linux
ac_cv_host_alias=i686-intel-linux
ac_cv_objext=o
ac_cv_path_PERL=/usr/bin/perl
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=gawk
ac_cv_prog_CPP='gcc -E'
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_CXX=g++
ac_cv_prog_ac_ct_RANLIB=ranlib
ac_cv_prog_cc_g=yes
ac_cv_prog_cxx_g=yes
ac_cv_prog_make_make_set=yes
ac_cv_type_off_t=yes
ac_cv_type_signal=void
ac_cv_type_size_t=yes
ac_cv_type_uid_t=yes
am_cv_CC_dependencies_compiler_type=gcc3
am_cv_CXX_dependencies_compiler_type=gcc3

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "valgrind"
#define VERSION "1.9.5"
#ifdef __cplusplus
#include <stdlib.h>
#endif
#define KERNEL_2_4 1
#define GLIBC_2_2 1
#define HAVE_SCHED_PRIORITY 1
#define HAVE_NFDS_T 1
#define XFREE_4 1
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define HAVE_FCNTL_H 1
#define HAVE_MALLOC_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_SYS_STATFS_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_TERMIOS_H 1
#define HAVE_UNISTD_H 1
#define HAVE_UTIME_H 1
#define TIME_WITH_SYS_TIME 1
#define HAVE_STDLIB_H 1
#define HAVE_UNISTD_H 1
#define HAVE_GETPAGESIZE 1
#define HAVE_MMAP 1
#define RETSIGTYPE void
#define HAVE_MEMCHR 1
#define HAVE_MEMSET 1
#define HAVE_MKDIR 1
#define HAVE_STRCHR 1
#define HAVE_STRDUP 1
#define HAVE_STRPBRK 1
#define HAVE_STRRCHR 1
#define HAVE_STRSTR 1

configure: exit 0

Re: [Valgrind-users] RH8 & Glibc 2.3

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

> Is there a known problem with glibc 2.3 and valgrind on redhat 8.0?
> Any workarounds?

Hard to say, since you mention no specific details of any problem.
There is a threading problem -- some calls like accept, recv, 
select, poll, etc, can lead to all threads being blocked rather
than just one.  I've fixed this in the cvs head and will backport
the fix to 1.9.6.  It only afflicts glibc >= 2.3.2.

J



>
> Thanks,
> Bill
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind RH RPM packages for RH62, RH72, RH80 and RH9

[Madhu M K. <mm...@ya...>]

On Sun, 27 Apr 2003 20:03:39 +0200 (CEST) Dag Wieers <da...@wi...> wrote:

> I'm building valgrind for several versions of the Red Hat distribution. 
> You can find these packages at:

On this note, thanks to /., I hit upon:

http://alleyoop.sourceforge.net/

And felt mighty happy :). However, given that it wasn't announced on either the devel or user lists, perhaps it can do with more usage. Also, perhaps, it is time to add a GUI-front-ends-to-valgrind entry into the FAQ?

Cheerio,
M

 Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com

[Valgrind-users] RH8 & Glibc 2.3

[William D. <cab...@ho...>]

Greetings,

Is there a known problem with glibc 2.3 and valgrind on redhat 8.0?
Any workarounds?

Thanks,
Bill

[Valgrind-users] Valgrind RH RPM packages for RH62, RH72, RH80 and RH9

[Dag W. <da...@wi...>]

Hi,

I'm building valgrind for several versions of the Red Hat distribution.=20
You can find these packages at:

	http://dag.wieers.com/packages/valgrind/

Or have them installed automatically using apt as described on:

	http://dag.wieers.com/apt/


The RH9 package is build on a clean RH9 by doing 'unset CFLAGS' as=20
described in RH BugZilla #88846. make was not updated.


I also included a small C program that would check if NPTL threading was=20
supported (at runtime). But I superseded that with using getconf directly=
.=20
(This works on all distributions and is much cleaner.)

Using getconf was advised on a mailinglist somewhere (I can't remember=20
where exactly I read that.) However I have the source of the small C=20
program still in my SPEC file for educational purposes.)

It would be nice though if valgrind could check for itself if NPTL=20
threading is supported at loadtime ? Or at least take over my changes to=20
coregrind/valgrind.in so that it is check in runtime (instead of checking=
=20
at compile-time)

You can do this by doing:

perl -pi.orig -e 's|^nptl_threading=3D.*$|nptl_threading=3D"$(if getconf =
GNU_LIBPTHREAD_VERSION &>/dev/null; then echo "yes"; else echo "no"; fi)"=
|' coregrind/valgrind.in


PS These packages still have a problem with some private GLIBC symbols=20
that are in the dependencies of the package. I can't seem to fix this by=20
doing:

	%define __find_provides() /usr/lib/rpm/find-provides %* | grep -v '^libp=
thread.so'
	%define __find_requires() /usr/lib/rpm/find-requires %* | grep -v 'libc.=
so.6(GLIBC_PRIVATE)'

So unless I find a clean way of doing this, you might have to install wit=
h=20
--nodeps on some RH's (RH80 and RH73 afaik).

PS2 I'm not subscribed, please put me in CC if you have any remarks.

Kind regards,
--   dag wieers,  da...@wi...,  http://dag.wieers.com/   --
=ABAny errors in spelling, tact or fact are transmission errors=BB

Re: [Valgrind-users] Error using cachegrind

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

On Tuesday 22 April 2003 00:19, Nicholas Nethercote wrote:
> ...
> > Nick, we should add a implementation of getcwd() to V, and use absolute
> > file paths. But this still doesn't work with chroot() programs :-(
> > Another option: --dumpfile-fd=...
>
> How's this for a better solution:  let's abandon the creation of the
> cachegrind.out.<pid> file at startup.  Originally, Cachegrind aborted if
> it couldn't open the cachegrind.out.<pid> file, and I put the
> open-at-startup code in so that if it couldn't open the file, the abort
> would happen at the start of execution, not at the end after waiting what
> could be a long time.
>
> But then Cachegrind was changed so it didn't abort if the file couldn't be
> opened, because sometimes with --trace-children=yes it happened often (I
> can't remember why).
>
> So now there's absolutely no point in opening the file at the start and
> then reopening it at the end.  So I'd be happy to remove the opening at

Yes. 

> the start.  But, the cachegrind.out.<pid> file should really be written in
> the directory the program was invoked from, regardless of any cwd change

Yes again. To tell the true, the "--base=" CLO addition was a quick workaround 
for this problem, as there's no getcwd() in valgrind's libc. We should add it 
and use the cwd at program start as absolute path for the cachegrind.out 
files.

> commands during execution, so the getcwd() implementation still seems like
> a good idea.  Does this sound sensible, Josef?  I don't understand the
> chroot() problem, can you explain it to me, and how it interacts here?

After a chroot(), a process can only access files below the given root in 
chroot(), if the files wasn't opened already. E.g, when cachegrinding the FTP 
damon, you don't have access to the cwd at program start on dump time.
But I think this is neglectable, as chroot() is rare.

>
> N
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled REPE case

[Philippe E. <ph...@wa...>]

Julian Seward wrote:
> Hello.  I'm trying to put together bug fixes for 1.9.6.
> 
> Several people reported this panic:
> 
>    REPE then 0xF
> 
>    valgrind: the `impossible' happened:
>       Unhandled REPE case
> 
> I'd like to fix it, since it seems to afflict quite a number
> of people.  However, reading my Intel P4 documentation I can't
> figure out what instruction this is.
> 
> So: does anyone have a smallish test case I can use to reproduce
> this with?  Or (not so good, but it would be a help) can anyone
> tell me what the byte after the 0xF is?  You can find out
> by changing vg_to_ucode.c:4321 from
> 
>          VG_(printf)("REPE then 0x%x\n", (UInt)abyte);
> 
> to
> 
>          VG_(printf)("REPE then 0x%x 0x%x\n", (UInt)abyte,
>                                               (UInt)getUChar(eip));
> 
> I prefer a test case tho, so I can test any fix I make.

Sorry no test case. 0x66/0xF3/0xF2 prefix are valid
first byte opcode for some sse/ss2e instruction

e.g.

F3 0F 58/r   addss xmm1, xmm2/m32

they are listed in table Intel P4 documentation Doc P4
Volume 2 Table A-3 Two byte opcode map, in each cell some
insn specify an additionnal opcode which is in fact the
first byte of the instructions, if you already handle
0x66 0xF there is only a few new opcode else ...

regards,
Phil

[Valgrind-users] Need test case for: REPE then 0xF: Unhandled REPE case

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

Hello.  I'm trying to put together bug fixes for 1.9.6.

Several people reported this panic:

   REPE then 0xF

   valgrind: the `impossible' happened:
      Unhandled REPE case

I'd like to fix it, since it seems to afflict quite a number
of people.  However, reading my Intel P4 documentation I can't
figure out what instruction this is.

So: does anyone have a smallish test case I can use to reproduce
this with?  Or (not so good, but it would be a help) can anyone
tell me what the byte after the 0xF is?  You can find out
by changing vg_to_ucode.c:4321 from

         VG_(printf)("REPE then 0x%x\n", (UInt)abyte);

to

         VG_(printf)("REPE then 0x%x 0x%x\n", (UInt)abyte,
                                              (UInt)getUChar(eip));

I prefer a test case tho, so I can test any fix I make.

Thanks,

J

Re: [Valgrind-users] Why doesn't freed C++ string memory when program exits?

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

Thanks to you both.  I've added this to the FAQ.

J


On Saturday 26 April 2003 3:08 pm, Bastien Chevreux wrote:
> On Saturday 26 April 2003 11:58, Julian Seward wrote:
> > Yes it is definitely one for the recently-expanded FAQ.  Some more
> > info (or the complete FAQ entry :) would be helpful.  Specifically,
> > can you say how to disable the STL's memory pooling, since that will
> > be the next thing that people ask having read the below.
>
> Hi there,
>
> I took Philippes answer and put in some additional information I had. See
> below.
>
> On a related sidenote, I have the soon to be 3.3, and using
> GLIBCPP_FORCE_NEW does not work for me (while -D__USE_MALLOC already
> produces compiler errors). Tested this with that small program:
>
> ------------------------------------------------
> #include<iostream>
> #include<deque>
> #include<set>
> using namespace std;
> void f1(int ic)
> {
>   set<char> n;
>   for(char c='a'; c < 'z'; c++) n.insert(c);
>   deque<set<char> > v;
>   for(int i=0; i<ic; i++) v.push_back(n);
> }
> int main(){
>   f1(1000);
>   cout << "The memory footprint ..." << endl;
>   f1(20000);
>   cout << "... should be ..." << endl;
>   f1(50000);
>   cout << "... near zero exactly now! (it isn't *sigh*)" << endl;
>   while(1);
>   return 0;
> }
> ------------------------------------------------
>
> And made a "setenv GLIBCPP_FORCE_NEW 1" before running the program -> still
> 30M memory imprint at the while loop. Anyone else seen this?
>
> Here's my proposal for the FAQ:
>
> Q14.  My program uses the C++ STL and string classes. Valgrind reports
> 'still reachable' memory leaks involving these classes at the exit of the
> program, but there should be none?!
>
> A14.  First of all: relax, it's probably not a bug, but a feature. Many
> implementations of the C++ standard libraries use own memory pool
> allocators. Memory for quite a number of destructed objects is not
> immediately freed and given back to the OS, but kept in the pool(s) for
> later re-use. The fact that the pools are not freed at the exit() of the
> program trigger valgrind. The behaviour not to free pools at the exit()
> could be called a bug of the library though.
>
> Using gcc, you can force the STL to use malloc and to free memory as soon
> as possible by globally disabling memory caching. Beware! Doing so will
> probably slow down your program, sometimes drastically.
>
> - With gcc 2.91, 2.95, 3.0 and 3.1 compile all source using the STL with
>   -D__USE_MALLOC. Beware! This is removed from gcc starting with version
> 3.3. - With 3.2.2 and later, you should export the environment variable
> GLIBCPP_FORCE_NEW before running your program.
>
> There are other ways to disable memory pooling: using the malloc_alloc
> template with your objects (not portable, but should work for gcc) or even
> writing your own memory allocators. But all this goes beyond the scope of
> this FAQ. Start with reading
>       http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3
> if you absolutely want to do that. But beware:
>   1) there are currently changes underway for gcc which are not totally
> reflected in the docs right now.
>   2) allocators belong to the more messy parts of the STL and people went
> at great lengths to make it portable across platforms. Chances are good
> that your solution will work on your platform, but not on others.

Re: [Valgrind-users] identifying variables w/ unfreed memory

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

On Saturday 26 April 2003 22:52, Leland Hovey wrote:
> I'm currently unable to identify the source of unfreed memory in my
> program.  The following valgrind diagnotics don't list a line number or
> variable name.
> However I'm using vectors and vector iterators so these could cause the
> problem.
> [...]

You have run into something which is actually being discussed as a candidate 
for the FAQ :-) However, as of now, sf.net seems to have problems with 
archived mailing lists (it keeps telling me that the valgerind-users list is 
not archived yet, pah!), so I'll send it to you just after this mail as there 
is no need to repost it.

Salut,
      Bastien

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

[Valgrind-users] identifying variables w/ unfreed memory

[Leland H. <lh...@ec...>]

Hello,

I'm currently unable to identify the source of unfreed memory in my
program.  The following valgrind diagnotics don't list a line number or
variable name.

However I'm using vectors and vector iterators so these could cause the
problem.

FYI I use the following valgrind-1.9.5 options:

valgrind -v --leak-check=yes --gdb-attach=yes --show-reachable=yes
--trace-malloc=yes --leak-resolution=high --show-reachable=yes
--gdb-attach=yes main

How can I id the variable(s)?

thanks,
Leland H.


==23908== 13936 bytes in 5 blocks are still reachable in loss record 1 of
1
==23908==    at 0x4016A068: malloc (vg_clientfuncs.c:103)
==23908==    by 0x8052FDF: __default_alloc_template<true,
0>::_S_chunk_alloc(unsigned int, int &)
(/usr/local/gcc-2.95.3/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_alloc.h:490)
==23908==    by 0x805310C: __default_alloc_template<true,
0>::_S_refill(unsigned int)
(/usr/local/gcc-2.95.3/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_alloc.h:531)
==23908==    by 0x805414B: __default_alloc_template<true,
0>::allocate(unsigned int)
(/usr/local/gcc-2.95.3/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_alloc.h:419)
==23908==
==23908== LEAK SUMMARY:
==23908==    definitely lost: 0 bytes in 0 blocks.
==23908==    possibly lost:   0 bytes in 0 blocks.
==23908==    still reachable: 13936 bytes in 5 blocks.
==23908==         suppressed: 0 bytes in 0 blocks.
==23908==

Re: [Valgrind-users] Why doesn't freed C++ string memory when program exits?

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

On Saturday 26 April 2003 11:58, Julian Seward wrote:
> Yes it is definitely one for the recently-expanded FAQ.  Some more
> info (or the complete FAQ entry :) would be helpful.  Specifically,
> can you say how to disable the STL's memory pooling, since that will
> be the next thing that people ask having read the below.

Hi there,

I took Philippes answer and put in some additional information I had. See 
below.

On a related sidenote, I have the soon to be 3.3, and using GLIBCPP_FORCE_NEW 
does not work for me (while -D__USE_MALLOC already produces compiler errors). 
Tested this with that small program:

------------------------------------------------
#include<iostream>
#include<deque>
#include<set>
using namespace std;
void f1(int ic)
{
  set<char> n;
  for(char c='a'; c < 'z'; c++) n.insert(c);
  deque<set<char> > v;
  for(int i=0; i<ic; i++) v.push_back(n);
}
int main(){
  f1(1000);
  cout << "The memory footprint ..." << endl;
  f1(20000);
  cout << "... should be ..." << endl;
  f1(50000);
  cout << "... near zero exactly now! (it isn't *sigh*)" << endl;
  while(1);
  return 0;
}
------------------------------------------------

And made a "setenv GLIBCPP_FORCE_NEW 1" before running the program -> still 
30M memory imprint at the while loop. Anyone else seen this?

Here's my proposal for the FAQ:

Q14.  My program uses the C++ STL and string classes. Valgrind reports 'still 
reachable' memory leaks involving these classes at the exit of the program, 
but there should be none?!

A14.  First of all: relax, it's probably not a bug, but a feature. Many 
implementations of the C++ standard libraries use own memory pool allocators. 
Memory for quite a number of destructed objects is not immediately freed and 
given back to the OS, but kept in the pool(s) for later re-use. The fact that 
the pools are not freed at the exit() of the program trigger valgrind. The 
behaviour not to free pools at the exit() could be called a bug of the 
library though.

Using gcc, you can force the STL to use malloc and to free memory as soon as 
possible by globally disabling memory caching. Beware! Doing so will probably 
slow down your program, sometimes drastically.

- With gcc 2.91, 2.95, 3.0 and 3.1 compile all source using the STL with
  -D__USE_MALLOC. Beware! This is removed from gcc starting with version 3.3.   
- With 3.2.2 and later, you should export the environment variable
  GLIBCPP_FORCE_NEW before running your program.

There are other ways to disable memory pooling: using the malloc_alloc 
template with your objects (not portable, but should work for gcc) or even 
writing your own memory allocators. But all this goes beyond the scope of 
this FAQ. Start with reading
      http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3
if you absolutely want to do that. But beware:
  1) there are currently changes underway for gcc which are not totally 
reflected in the docs right now.
  2) allocators belong to the more messy parts of the STL and people went at 
great lengths to make it portable across platforms. Chances are good that 
your solution will work on your platform, but not on others.

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

Re: [Valgrind-users] Why doesn't freed C++ string memory when program exits?

[Philippe E. <ph...@wa...>]

Julian Seward wrote:
> Yes it is definitely one for the recently-expanded FAQ.  Some more 
> info (or the complete FAQ entry :) would be helpful.  Specifically,
> can you say how to disable the STL's memory pooling, since that will
> be the next thing that people ask having read the below.

feel free to change the wording if there is any problem.

btw I posted syscall 253 implementation a week ago. Any comment ?

http://sourceforge.net/mailarchive/forum.php?thread_id=1982441&forum_id=12302

regards,
Phil

Re: [Valgrind-users] Why doesn't freed C++ string memory when program exits?

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

Yes it is definitely one for the recently-expanded FAQ.  Some more 
info (or the complete FAQ entry :) would be helpful.  Specifically,
can you say how to disable the STL's memory pooling, since that will
be the next thing that people ask having read the below.

Thx

J

On Saturday 26 April 2003 10:42 am, Bastien Chevreux wrote:
> On Saturday 26 April 2003 02:03, Lee, HJ wrote:
> > If I use string type for example ---> string a("Hello, world"), the
> > memory allocated for string isn't freed when program exit.
> > valgrand reported it is not-freed block. Here is valgrind reports logs.
> > Why is it not freed when program exits? I am using RH6.2.
>
> The thread ""Reachable" memory, where's the bug (g++, STL, valgrind)?"
> might help you there. In short: the C++ STL and string function have their
> own memory pooling mechanisms to gain speed. The memory of these objects is
> not 'freed' per se when they are destructed, but returned to the internal
> memory pool and will be reused for other objects created. It's these pool
> fragments (which are not freed by the C++ library before exit) that
> valgrind chokes on.
>
> While you can minimise this behaviour with the STL by providing your own
> allocators (not recommended, slows down execution speed terribly on some
> systems), I am not aware of similar mechanisms for the string classes.
>
> Salut,
>       Bastien
>
> PS: This is _definitively_ something for the FAQ.

Re: [Valgrind-users] Why doesn't freed C++ string memory when program exits?

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

On Saturday 26 April 2003 02:03, Lee, HJ wrote:
> If I use string type for example ---> string a("Hello, world"), the memory
> allocated for string isn't freed when program exit.
> valgrand reported it is not-freed block. Here is valgrind reports logs.
> Why is it not freed when program exits? I am using RH6.2.

The thread ""Reachable" memory, where's the bug (g++, STL, valgrind)?" might 
help you there. In short: the C++ STL and string function have their own 
memory pooling mechanisms to gain speed. The memory of these objects is not 
'freed' per se when they are destructed, but returned to the internal memory 
pool and will be reused for other objects created. It's these pool fragments 
(which are not freed by the C++ library before exit) that valgrind chokes on.

While you can minimise this behaviour with the STL by providing your own 
allocators (not recommended, slows down execution speed terribly on some 
systems), I am not aware of similar mechanisms for the string classes.

Salut,
      Bastien

PS: This is _definitively_ something for the FAQ.

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