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
(6) |
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: Jeremy F. <je...@go...> - 2003-04-02 19:22:31
|
On Wed, 2003-04-02 at 10:28, David Eriksson wrote:
> Strace stops in poll, and if I attach to the server process with gdb I
> get this stacktrace:
>
> (gdb) bt
> #0 0x40183272 in vgPlain_do_syscall () from
> /usr/local/lib/valgrind/valgrind.so
> #1 0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0
> #2 0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60)
> at vg_intercept.c:194
> #3 0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0
> #4 0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
> #5 0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
> #6 0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616
> #7 0x403d3907 in __libc_start_main () from /lib/libc.so.6
Hm, looks like the vg_intercept stuff isn't working - it's catching
poll, but it isn't passing it into the threads library properly. What
does ldd <your program> say? What is in /proc/<pid>/maps when you run
it? What does the link command line look like?
Did you manage to get a small standalone program to reproduce the
problem?
J
|
|
From: David E. <da...@2g...> - 2003-04-02 18:56:33
|
On Wed, 2003-04-02 at 19:53, Jeremy Fitzhardinge wrote: > On Wed, 2003-04-02 at 09:02, David Eriksson wrote: > > For the fun of it, I tried to send a SIGHUP to my process. There is > > singal handler installed with signal() for SIGHUP, which gets executed > > properly. What also happens is that all threads (one for each connection > > that have been made to the server) get to run! > > > > Do you have any ideas? > > > > I will happily provide any more information that may be of interest. > What does strace have to say about your running process? Is it > blocked in a a system call, or does it seem to be spinning away > happily? > > It's possible that the libc poll (or some other blocking system call) > is somehow getting called without being intercepted by Valgrind. Strace stops in poll, and if I attach to the server process with gdb I get this stacktrace: (gdb) bt #0 0x40183272 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so #1 0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0 #2 0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60) at vg_intercept.c:194 #3 0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0 #4 0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #5 0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0 #6 0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616 #7 0x403d3907 in __libc_start_main () from /lib/libc.so.6 -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: David E. <da...@2g...> - 2003-04-02 18:50:30
|
On Wed, 2003-04-02 at 19:41, Jeff Johnson wrote: > On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote: > > Hello, > > > > First, the obligatory credits: Thank you very much for writing valgrind! > > > > When I recently subscribed to this mailing list I read a message from > > Nicholas Nethercote where he said that 1.9.4 was more stable and worked > > better than 1.0.4 so I thought I'd give it a try. > > > > However, it seems to me like something has changed between the two > > versions, maybe regarding the combination threads and sockets. > > > > I am running RedHat 8.0, with the latest updates installed: > > > > kernel-2.4.18-27.8.0 > > glibc-2.3.2-4.80 > > gcc-3.2-7 > > > > The application I'm examining with valgrind is a threaded server > > application written in C that uses glib. It is quite large and > > complicated to install, so there is no point in providing it. > > > > I have tried to make a scaled-down example to reproduce my problem. It > > is not finished yet, but I thought that I'll try to describe the problem > > in case anyone has any suggestions: > > > > The server creates a unix socket and makes glib poll() the socket for > > events. A client connects to the server, which accept() the connection > > and creates a new thread for handling the connection. > > > > By using simple "printf debugging" it seems like the the new thread > > never gets scheduled to run in valgrind 1.9.4. > > > > For the fun of it, I tried to send a SIGHUP to my process. There is > > singal handler installed with signal() for SIGHUP, which gets executed > > properly. What also happens is that all threads (one for each connection > > that have been made to the server) get to run! > > > > Do you have any ideas? > > FYI: You're running a NPTL capable library with a NPTL deprived kernel. > > Meanwhile, prefix your valgrind command with > LD_ASSUME_KERNEL=2.2.5 valgrind ... > to force use of Good Old libpthread. Well, pthread is never loaded when using valgrind as valgrind maintains its own thread scheduling: ... ==29456== Reading syms from /usr/local/lib/valgrind/libpthread.so ... -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Brian W. <bri...@av...> - 2003-04-02 18:50:20
|
Hello all,
I have downloaded valgrind-1.0.4 on a RedHat 8.0 with a 2.4.18-14smp kernel
and did the ./configure, make and make install without a problem. I then
tried to build a rpm package using the valgrind.spec file which create the
valgrind-1.0.4 using rpmbuild -ba valgrind.spec and everything looked good
until I tried to install the rpm I got the following failed dependency
error.
error: Failed dependencies:
libc.so.6(GLIBC_PRIVATE) is needed by valgrind-1.0.4-1
I did a strings /lib/libc.so.6 |grep -i private and it did return
GLIBC_PRIVATE.
Has anyone got this to work?
Brian S. Wince
Sr. Unix/Linux Administrator
Information Technology
AltaVista
bri...@av...
650.320.6485
|
|
From: Olly B. <ol...@su...> - 2003-04-02 17:56:31
|
On Wed, Apr 02, 2003 at 09:49:46AM -0800, Jeremy Fitzhardinge wrote:
> On Wed, 2003-04-02 at 08:34, Olly Betts wrote:
>
> > On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > > > > {
> > > > > std::string s;
> > > > > s += '0';
> > > > > }
> > > > > exit(0);
> >
> > > Just out of curiosity, why would s be destructed if you call exit()?
> >
> > s is destructed at the end of the block where it's defined - i.e. the
> > line before exit is called.
>
> Do you mean the compiler is treating exit specially?
No. Look at the code. s is destructed at the end of the block it is
defined in. That's how C++ works. What happens after the block is
irrelevant to that destruction.
> Is that because
> its a noreturn function? That still can't be right: if it were a
> noreturn function which takes a std::string argument, then it would be
> wrong to destruct the string before passing it.
But it couldn't take s as an argument, as s isn't in scope at that
point!
Cheers,
Olly
|
|
From: Jeremy F. <je...@go...> - 2003-04-02 17:55:01
|
On Wed, 2003-04-02 at 09:10, Maarten Ballintijn wrote:
> Thanks! Silly me, completely missed the extra braces :-/
Oh, yeah. Mass silliness.
J
|
|
From: Jeremy F. <je...@go...> - 2003-04-02 17:53:51
|
On Wed, 2003-04-02 at 09:02, David Eriksson wrote:
> For the fun of it, I tried to send a SIGHUP to my process. There is
> singal handler installed with signal() for SIGHUP, which gets executed
> properly. What also happens is that all threads (one for each connection
> that have been made to the server) get to run!
>
> Do you have any ideas?
>
> I will happily provide any more information that may be of interest.
What does strace have to say about your running process? Is it blocked
in a a system call, or does it seem to be spinning away happily?
It's possible that the libc poll (or some other blocking system call) is
somehow getting called without being intercepted by Valgrind.
J
|
|
From: Jeremy F. <je...@go...> - 2003-04-02 17:51:45
|
On Wed, 2003-04-02 at 09:41, Jeff Johnson wrote:
> FYI: You're running a NPTL capable library with a NPTL deprived kernel.
>
> Meanwhile, prefix your valgrind command with
> LD_ASSUME_KERNEL=2.2.5 valgrind ...
> to force use of Good Old libpthread.
Are you sure? There's only one libpthread in that glibc package; can
the one library do both NPTL and linuxthreads?
J
|
|
From: Jeremy F. <je...@go...> - 2003-04-02 17:49:49
|
On Wed, 2003-04-02 at 08:34, Olly Betts wrote:
> On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > > > {
> > > > std::string s;
> > > > s += '0';
> > > > }
> > > > exit(0);
>
> > Just out of curiosity, why would s be destructed if you call exit()?
>
> s is destructed at the end of the block where it's defined - i.e. the
> line before exit is called.
Do you mean the compiler is treating exit specially? Is that because
its a noreturn function? That still can't be right: if it were a
noreturn function which takes a std::string argument, then it would be
wrong to destruct the string before passing it.
J
|
|
From: Jeff J. <jb...@re...> - 2003-04-02 17:41:38
|
On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote: > Hello, > > First, the obligatory credits: Thank you very much for writing valgrind! > > When I recently subscribed to this mailing list I read a message from > Nicholas Nethercote where he said that 1.9.4 was more stable and worked > better than 1.0.4 so I thought I'd give it a try. > > However, it seems to me like something has changed between the two > versions, maybe regarding the combination threads and sockets. > > I am running RedHat 8.0, with the latest updates installed: > > kernel-2.4.18-27.8.0 > glibc-2.3.2-4.80 > gcc-3.2-7 > > The application I'm examining with valgrind is a threaded server > application written in C that uses glib. It is quite large and > complicated to install, so there is no point in providing it. > > I have tried to make a scaled-down example to reproduce my problem. It > is not finished yet, but I thought that I'll try to describe the problem > in case anyone has any suggestions: > > The server creates a unix socket and makes glib poll() the socket for > events. A client connects to the server, which accept() the connection > and creates a new thread for handling the connection. > > By using simple "printf debugging" it seems like the the new thread > never gets scheduled to run in valgrind 1.9.4. > > For the fun of it, I tried to send a SIGHUP to my process. There is > singal handler installed with signal() for SIGHUP, which gets executed > properly. What also happens is that all threads (one for each connection > that have been made to the server) get to run! > > Do you have any ideas? FYI: You're running a NPTL capable library with a NPTL deprived kernel. Meanwhile, prefix your valgrind command with LD_ASSUME_KERNEL=2.2.5 valgrind ... to force use of Good Old libpthread. 73 de Jeff -- Jeff Johnson ARS N3NPQ jb...@re... (jb...@jb...) Chapel Hill, NC |
|
From: David E. <da...@2g...> - 2003-04-02 17:30:26
|
Hello, First, the obligatory credits: Thank you very much for writing valgrind! When I recently subscribed to this mailing list I read a message from Nicholas Nethercote where he said that 1.9.4 was more stable and worked better than 1.0.4 so I thought I'd give it a try. However, it seems to me like something has changed between the two versions, maybe regarding the combination threads and sockets. I am running RedHat 8.0, with the latest updates installed: kernel-2.4.18-27.8.0 glibc-2.3.2-4.80 gcc-3.2-7 The application I'm examining with valgrind is a threaded server application written in C that uses glib. It is quite large and complicated to install, so there is no point in providing it. I have tried to make a scaled-down example to reproduce my problem. It is not finished yet, but I thought that I'll try to describe the problem in case anyone has any suggestions: The server creates a unix socket and makes glib poll() the socket for events. A client connects to the server, which accept() the connection and creates a new thread for handling the connection. By using simple "printf debugging" it seems like the the new thread never gets scheduled to run in valgrind 1.9.4. For the fun of it, I tried to send a SIGHUP to my process. There is singal handler installed with signal() for SIGHUP, which gets executed properly. What also happens is that all threads (one for each connection that have been made to the server) get to run! Do you have any ideas? I will happily provide any more information that may be of interest. Regards, -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Maarten B. <maa...@mi...> - 2003-04-02 17:11:04
|
Hi,
Thanks! Silly me, completely missed the extra braces :-/
Maarten.
On Wed, 2003-04-02 at 11:34, Olly Betts wrote:
> On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > > > {
> > > > std::string s;
> > > > s += '0';
> > > > }
> > > > exit(0);
>
> > Just out of curiosity, why would s be destructed if you call exit()?
>
> s is destructed at the end of the block where it's defined - i.e. the
> line before exit is called.
>
> Cheers,
> Olly
>
|
|
From: Olly B. <ol...@su...> - 2003-04-02 16:35:55
|
On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > > {
> > > std::string s;
> > > s += '0';
> > > }
> > > exit(0);
> Just out of curiosity, why would s be destructed if you call exit()?
s is destructed at the end of the block where it's defined - i.e. the
line before exit is called.
Cheers,
Olly
|
|
From: Maarten B. <maa...@mi...> - 2003-04-02 16:23:42
|
Hello,
Just out of curiosity, why would s be destructed if you call exit()?
I find it somewhat hard to believe (counter intuitive, even unwanted)
that calling exit() from inside maybe a 10 level deep calling sequence
would cause all stack based variables to be destructed?
Thanks for any insights!
Cheers,
Maarten.
On Tue, 2003-04-01 at 23:36, Geoff Alexander wrote:
>
> ----- Original Message -----
> From: Jeremy Fitzhardinge
> To: Geoff Alexander
> Cc: val...@li...
> Sent: Tuesday, April 01, 2003 1:31 AM
> Subject: Re: [Valgrind-users] "still reachable" memory from
> g++'sstd::string
> On Mon, 2003-03-31 at 20:47, Geoff Alexander wrote:
> > In running valgrind 1.0.4 against a small program of mine,
> > valgrind reports "still reachable" memory at exit, both with
> > g++ 2.95.2 and gcc 3.2 on SuSE Linux x86 7.1. I've tracked
> > the problem down to std::string. Here's a small program
> > that illustrates the problem:
> > #include <cstdlib>
> > #include <string>
> > int main(int argc, char* argv[])
> > {
> > {
> > std::string s;
> > s += '0';
> > }
> > exit(0);
> > }
>
> What happens if you return 0 rather than exit(0)? I'm not
> sure that s will necessarily have been destructed if you use
> exit.
> J
> Thanks for the suggestion. Using return 0 rather than exit(0) didn't
> change anything. I verified under gdb that s is being destructed in
> both cases.
>
> Geoff Alexander
--
Maarten Ballintijn <maa...@mi...>
Massachusetts Institute of Technology
|
|
From: Geoff A. <gal...@nc...> - 2003-04-02 05:05:21
|
----- Original Message -----=20
From: "Nicholas Nethercote" <nj...@ca...>
To: "Geoff Alexander" <gal...@nc...>
Cc: <val...@li...>
Sent: Tuesday, April 01, 2003 5:08 AM
Subject: Re: [Valgrind-users] "still reachable" memory from g++'s =
std::string
> On Mon, 31 Mar 2003, Geoff Alexander wrote:
>=20
> > In running valgrind 1.0.4 against a small program of mine, valgrind =
reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc =
3.2 on SuSE Linux x86 7.1. I've tracked the problem down to =
std::string. Here's a small program that illustrates the problem:
> > #include <cstdlib>
> > #include <string>
> > int main(int argc, char* argv[])
> > {
> > {
> > std::string s;
> > s +=3D '0';
> > }
> > exit(0);
> > }
> > Under g++ 2.95.2, valgrind reports:
> > =3D=3D1214=3D=3D LEAK SUMMARY:
> > =3D=3D1214=3D=3D definitely lost: 0 bytes in 0 blocks.
> > =3D=3D1214=3D=3D possibly lost: 0 bytes in 0 blocks.
> > =3D=3D1214=3D=3D still reachable: 1280 bytes in 1 blocks.
> > and under g++ 3.2, valgrind reports:
> > =3D=3D1236=3D=3D LEAK SUMMARY:
> > =3D=3D1236=3D=3D definitely lost: 0 bytes in 0 blocks.
> > =3D=3D1236=3D=3D possibly lost: 0 bytes in 0 blocks.
> > =3D=3D1236=3D=3D still reachable: 640 bytes in 1 blocks.
> >
> > Note that the amount of memory report as "still reachable" grows =
larger
> > as more characters are appended to s. I suspect that the "still
> > reachable" memory is a static buffer allocated in std::string, =
rather
> > than leaked memory. Is this correct? If so, is there way to tell
> > valgrind not to report the memory allocated this std::string static
> > buffer.
>=20
> It shouldn't be static -- the leak checker only considers dynamically
> allocated blocks.
>=20
> It sounds pretty harmless, if you want to suppress it, download v1.9.4 =
and
> use the "Leak" suppression type (1.0.4 doesn't support it). Ignore =
what
> it says about 1.9.4 being "development" -- it's more stable and =
generally
> better than 1.0.4. Note that you have to write the suppression type =
as
> "Memcheck:Leak" for 1.9.4, see the supplied .supp files for examples.
> Also note that when writing suppressions you have to give the =
_mangled_
> name for C++ functions -- use the --demangle=3Dno option to Valgrind =
to find
> them out.
>=20
> HTH.
>=20
> N
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:=20
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
Thanks for the suggestions. I realize the leak checker only considers =
dynamically allocated blocks. What I meant by "static buffer" is that =
the address of the dynamically allocated block is being saved in a =
static variable (really a misuse of the term "static buffer") and not =
being freed when s is destructed. I investigated this further, and =
indeed this is the case. In both g++ 2.95.2 and g++ 3.2, the allocated =
memory is being saved in the
static char* _S_start_free
member of
template <bool threads, int inst> class __default_alloc_template
which is defined in stl_alloc.h (g++ 2.95.2) or bits/stl_alloc.h (g++ =
3.2). So, it seems that the "leaked" memory is allocated as part of =
gcc's STL memory management. I was able to suppress the leak using =
valgrind 1.9.4. For g++ 2.95.2, my suppression file is
#-------- For g++ 2.95.2
{
malloc/__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned =
int, int &)
Memcheck:Leak
fun:malloc
fun:_S_chunk_alloc__t24__default_alloc_template2b1i0UiRi
}
and for g++ 3.2, my suppression file is
#-------- For g++ 3.2
{
__builtin_new/operator =
new(unsigned)/std::__default_alloc_template<true, =
0>::_S_chunk_alloc(unsigned, int&)
Memcheck:Leak
fun:__builtin_new
fun:_Znwj
fun:_ZNSt24__default_alloc_templateILb1ELi0EE14_S_chunk_allocEjRi
}
Thanks again for your help.
Geoff Alexander |
|
From: Geoff A. <gal...@nc...> - 2003-04-02 04:34:17
|
----- Original Message -----=20
From: Jeremy Fitzhardinge=20
To: Geoff Alexander=20
Cc: val...@li...=20
Sent: Tuesday, April 01, 2003 1:31 AM
Subject: Re: [Valgrind-users] "still reachable" memory from =
g++'sstd::string
On Mon, 2003-03-31 at 20:47, Geoff Alexander wrote:=20
In running valgrind 1.0.4 against a small program of mine, valgrind =
reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc =
3.2 on SuSE Linux x86 7.1. I've tracked the problem down to =
std::string. Here's a small program that illustrates the problem:=20
#include <cstdlib>
#include <string>
int main(int argc, char* argv[])
{
{
std::string s;
s +=3D '0';
}
exit(0);
}=20
What happens if you return 0 rather than exit(0)? I'm not sure that s =
will necessarily have been destructed if you use exit.=20
J=20
Thanks for the suggestion. Using return 0 rather than exit(0) didn't =
change anything. I verified under gdb that s is being destructed in =
both cases.
Geoff Alexander |