You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: William D. <cab...@ho...> - 2003-04-28 18:23:07
|
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 > > |
|
From: Nicholas N. <nj...@ca...> - 2003-04-28 17:43:02
|
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 |
|
From: Bill D. <cab...@ho...> - 2003-04-28 17:25:28
|
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 |
|
From: Nicholas N. <nj...@ca...> - 2003-04-28 13:49:27
|
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 |
|
From: <ar...@fl...> - 2003-04-28 13:38:25
|
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 |
|
From: Nicholas N. <nj...@ca...> - 2003-04-28 12:51:25
|
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 |
|
From: <sd...@cl...> - 2003-04-28 12:32:05
|
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
|
|
From: Julian S. <js...@ac...> - 2003-04-28 07:44:27
|
> 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 |
|
From: Madhu M K. <mm...@ya...> - 2003-04-28 05:10:32
|
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 |
|
From: William D. <cab...@ho...> - 2003-04-28 03:00:07
|
Greetings, Is there a known problem with glibc 2.3 and valgrind on redhat 8.0? Any workarounds? Thanks, Bill |
|
From: Dag W. <da...@wi...> - 2003-04-27 18:04:13
|
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 |
|
From: Josef W. <Jos...@gm...> - 2003-04-27 14:31:38
|
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 |
|
From: Philippe E. <ph...@wa...> - 2003-04-27 00:49:12
|
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
|
|
From: Julian S. <js...@ac...> - 2003-04-26 23:13:47
|
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
|
|
From: Julian S. <js...@ac...> - 2003-04-26 22:24:04
|
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.
|
|
From: Bastien C. <ba...@ch...> - 2003-04-26 22:06:13
|
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. -- |
|
From: Leland H. <lh...@ec...> - 2003-04-26 20:52:36
|
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== |
|
From: Bastien C. <ba...@ch...> - 2003-04-26 14:07:58
|
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. --
|
|
From: Philippe E. <ph...@wa...> - 2003-04-26 11:13:57
|
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 |
|
From: Julian S. <js...@ac...> - 2003-04-26 09:58:54
|
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.
|
|
From: Bastien C. <ba...@ch...> - 2003-04-26 09:41:47
|
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. --
|
|
From: Lee, H. <HJ...@ec...> - 2003-04-26 00:03:31
|
Hi,
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.
----------------
==2264== Addrcheck, a fine-grained address checker for x86-linux.
==2264== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==2264== Using valgrind-1.9.5, a program instrumentation system for
x86-linux.
==2264== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==2264==
==2264== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2264== malloc/free: in use at exit: 1280 bytes in 1 blocks.
==2264== malloc/free: 1 allocs, 0 frees, 1280 bytes allocated.
==2264== For counts of detected errors, rerun with: -v
==2264== searching for pointers to 1 not-freed blocks.
==2264== checked 3490188 bytes.
==2264==
==2264== 1280 bytes in 1 blocks are still reachable in loss record 1 of 1
==2264== at 0x4014D4C8: malloc (in /usr/local/lib/valgrind/valgrind.so)
==2264== by 0x4021B96F: __default_alloc_template<true,
0>::chunk_alloc(unsigned int, int &) (in
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x4021BA28: __default_alloc_template<true,
0>::refill(unsigned int) (in /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x402140F2: basic_string<char, string_char_traits<char>,
__default_alloc_template<true, 0> >::replace(unsigned int, unsigned int,
char const *, unsigned int) (in /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x402169B7: basic_string<char, string_char_traits<char>,
__default_alloc_template<true, 0> >::basic_string(char const *) (in
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x804A1D4: main (str_test.cpp:19)
==2264== by 0x402729CA: __libc_start_main (in /lib/libc-2.1.3.so)
==2264== by 0x804A130: ??? (/usr/include/g++-2/stl_alloc.h:533)
==2264==
==2264== LEAK SUMMARY:
==2264== definitely lost: 0 bytes in 0 blocks.
==2264== possibly lost: 0 bytes in 0 blocks.
==2264== still reachable: 1280 bytes in 1 blocks.
==2264== suppressed: 0 bytes in 0 blocks.
------------------
HJ
|
|
From: Vimal R. <vim...@ya...> - 2003-04-25 23:10:01
|
Hi,
I am getting an Abort signal when I run valgrind on GNU smalltalk. The problem
(I think) seems to be with the signal handlers. GNU Smalltalk sets its own
signal handlers. After reading the documentation (2.13.5 Signals), I feel the
problem is occurring after valgrind catches the signal, but the return back to
the client code's handler bombs.
Here is the output of valgrind :
/vimal/gst-linux-x86> valgrind --trace-signals=yes --error-limit=no
./gst ../smalltalk-2.1/tests/sets.st
See attached file : gst_output
I have included the program output separately at the end.
The combined output (if it helps to better see the sequence of events):
See attached file: combined_output
Here is the client signal hanlder code (just included the important functions)
:
See attached file : gst_signal_handler_code
Here is a look at the dynamic dependencies of gst:
/vimal/gst-linux-x86> ldd ./gst
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libdl.so.2 => /lib/libdl.so.2 (0x4002d000)
libreadline.so.4 => /usr/lib/libreadline.so.4 (0x40030000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40056000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4005a000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40082000)
libm.so.6 => /lib/i686/libm.so.6 (0x40097000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x400ba000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Another important thing to note is this happens only when the garbage collector
is invoked (I placed a command in the smalltalk file sets.st which forces
garbage collection). If I run the same file (sets.st) without invoking garbage
collection (GC) it runs perfectly. When the GC is invoked, there is surely some
particular signal thrown around (there is some new memory allocated, cleaned up
etc in the heap ) and I guess that is the one to look out for. I'm sorry, i'm
not in a position to pin point the problem as I'm just a user of GNU Smalltalk.
If you want to reproduce the problem, GNU Smalltalk-2.1 is there for download
here : http://www.gnu.org/software/smalltalk/ Or I can send you the copy I'm
using.
Please let me know if you need any more diagnostic information.
Thanks,
Vimal
=====
Vimal Reddy
Graduate Student, ECE
North Carolina State University
Raleigh, NC
Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2003-04-25 10:14:49
|
On Thu, 24 Apr 2003, Julian Seward wrote: > Writing a skin to do this should be very easy. I suggest you > start with the lackey skin. Or maybe the cacheprof one. > You can instrument the basic blocks in flexible ways as they > are passed to your skin. One simple thing to do is to call > function(s) of your choice when LOADs / STOREs, and their > FPU equivalents, happen. ( s/cacheprof/cachegrind ) Read the docs on how to write a skin; there should be a link to it from within the main docs, coregrind/docs/coregrind_skins.html if not. include/vg_skin.h contains all the declarations relevant for writing skins, it's worth reading to see what services Valgrind provides to make skin-writing easier. And yes, it should be about as easy as any skin to write. N |
|
From: Robert W. <rj...@du...> - 2003-04-25 01:46:59
|
> Sorry for off-topic, but I would like to ask Valgrind users a question - = no > doubt some of you have run into this. I am deeply interested in finding a > performance profiler that works without code recompilation. Gprof is grea= t, but > ... can't use it. Is there anything out there for Linux that works like > valgrind - on executalbles? Or at least on object files? I would truly > appreciate any feedback. Not at all off-topic :-) There's a patch to Valgrind to do this. Take a look at Jeremy Fitzhardinge's vgprof stuff. I'm not so sure how up-to-date it is with respect to the current CVS head, but it worked pretty well for me last time I tried it out. http://www.goop.org/~jeremy/valgrind/ This produces a gmon.out file that can be parsed by an updated version of gprof (which Jeremy also provides.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |