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: 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 |
|
From: Julian S. <js...@ac...> - 2003-04-01 22:50:21
|
In the longer run it would be nice to completely redesign the virtual CPU stuff, so that multiple architectures could be supported. The compiler technology for that kind of thing is well established. However, doing so would require substantial hacking input over a sustained period of time, and is not something that anyone can viably do in their spare time. So the prospects are not good. J On Tuesday 01 April 2003 10:17 pm, Nicholas Nethercote wrote: > On Tue, 1 Apr 2003, Markus Bernhardt wrote: > > Is there a chance valgrind will be ported to the upcoming > > ia-64 (Intel Itanium) architecture ? > > I wouldn't count on it, sorry. > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2003-04-01 22:17:45
|
On Tue, 1 Apr 2003, Markus Bernhardt wrote: > Is there a chance valgrind will be ported to the upcoming > ia-64 (Intel Itanium) architecture ? I wouldn't count on it, sorry. N |
|
From: Markus B. <Mar...@sc...> - 2003-04-01 13:57:23
|
First I like to say a big thank you to the authors and contributors of valgrind for this superb tool. It saved my life more than once. Is there a chance valgrind will be ported to the upcoming ia-64 (Intel Itanium) architecture ? I'm so used to develop with valgrind, it really hurts not having it. (You'll always recognize the worth of a tool if you don't have it any more) - markus |
|
From: Nicholas N. <nj...@ca...> - 2003-04-01 10:08:29
|
On Mon, 31 Mar 2003, Geoff Alexander wrote:
> In running valgrind 1.0.4 against a small program of mine, valgrind reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc 3.2 on SuSE Linux x86 7.1. I've tracked the problem down to std::string. Here's a small program that illustrates the problem:
> #include <cstdlib>
> #include <string>
> int main(int argc, char* argv[])
> {
> {
> std::string s;
> s += '0';
> }
> exit(0);
> }
> Under g++ 2.95.2, valgrind reports:
> ==1214== LEAK SUMMARY:
> ==1214== definitely lost: 0 bytes in 0 blocks.
> ==1214== possibly lost: 0 bytes in 0 blocks.
> ==1214== still reachable: 1280 bytes in 1 blocks.
> and under g++ 3.2, valgrind reports:
> ==1236== LEAK SUMMARY:
> ==1236== definitely lost: 0 bytes in 0 blocks.
> ==1236== possibly lost: 0 bytes in 0 blocks.
> ==1236== still reachable: 640 bytes in 1 blocks.
>
> Note that the amount of memory report as "still reachable" grows larger
> as more characters are appended to s. I suspect that the "still
> reachable" memory is a static buffer allocated in std::string, rather
> than leaked memory. Is this correct? If so, is there way to tell
> valgrind not to report the memory allocated this std::string static
> buffer.
It shouldn't be static -- the leak checker only considers dynamically
allocated blocks.
It sounds pretty harmless, if you want to suppress it, download v1.9.4 and
use the "Leak" suppression type (1.0.4 doesn't support it). Ignore what
it says about 1.9.4 being "development" -- it's more stable and generally
better than 1.0.4. Note that you have to write the suppression type as
"Memcheck:Leak" for 1.9.4, see the supplied .supp files for examples.
Also note that when writing suppressions you have to give the _mangled_
name for C++ functions -- use the --demangle=no option to Valgrind to find
them out.
HTH.
N
|
|
From: Jeremy F. <je...@go...> - 2003-04-01 06:31:52
|
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
|
|
From: Geoff A. <gal...@nc...> - 2003-04-01 04:45:45
|
In running valgrind 1.0.4 against a small program of mine, valgrind =
reports "still reachable" memory at exit, both with g++ 2.95.2 and gcc =
3.2 on SuSE Linux x86 7.1. I've tracked the problem down to =
std::string. Here's a small program that illustrates the problem:
#include <cstdlib>
#include <string>
int main(int argc, char* argv[])
{
{
std::string s;
s +=3D '0';
}
exit(0);
}
Under g++ 2.95.2, valgrind reports:
=3D=3D1214=3D=3D LEAK SUMMARY:
=3D=3D1214=3D=3D definitely lost: 0 bytes in 0 blocks.
=3D=3D1214=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D1214=3D=3D still reachable: 1280 bytes in 1 blocks.
and under g++ 3.2, valgrind reports:
=3D=3D1236=3D=3D LEAK SUMMARY:
=3D=3D1236=3D=3D definitely lost: 0 bytes in 0 blocks.
=3D=3D1236=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D1236=3D=3D still reachable: 640 bytes in 1 blocks.
Note that the amount of memory report as "still reachable" grows larger =
as more characters are appended to s. I suspect that the "still =
reachable" memory is a static buffer allocated in std::string, rather =
than leaked memory. Is this correct? If so, is there way to tell =
valgrind not to report the memory allocated this std::string static =
buffer.=20
Thanks,
Geoff Alexander |