public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
@ 2003-03-31 23:16 Carlo Wood
0 siblings, 0 replies; 6+ messages in thread
From: Carlo Wood @ 2003-03-31 23:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/10276; it has been noted by GNATS.
From: Carlo Wood <carlo@alinoe.com>
To: ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
Date: Tue, 1 Apr 2003 00:55:42 +0200
On Mon, Mar 31, 2003 at 05:20:22PM -0000, ehrhardt@mathematik.uni-ulm.de wrote:
> Do you actually see a memory leak? As far as I can see _M_dispose_callbacks()
> (called by the ios_base destructor) should free the memory.
Yes. See http://gcc.gnu.org/ml/libstdc++/2003-03/msg00373.html
And so does Ulrich Weigand (http://gcc.gnu.org/ml/libstdc++/2003-03/msg00338.html)
and apparently Benjamin Kosnik too for 3.4 (http://gcc.gnu.org/ml/libstdc++/2003-03/msg00361.html)
This PR should be assigned to Loren James Rittle I understood
(http://gcc.gnu.org/ml/libstdc++/2003-03/msg00353.html).
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
@ 2003-04-29 16:06 bkoz
0 siblings, 0 replies; 6+ messages in thread
From: bkoz @ 2003-04-29 16:06 UTC (permalink / raw)
To: bkoz, carlo, gcc-bugs, gcc-prs, nobody
Synopsis: memory leak for stringstream / ios_base callback cache.
Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Apr 29 16:06:21 2003
Responsible-Changed-Why:
Mine. This is still an open issue
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10276
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
@ 2003-04-01 9:49 ehrhardt
0 siblings, 0 replies; 6+ messages in thread
From: ehrhardt @ 2003-04-01 9:49 UTC (permalink / raw)
To: carlo, gcc-bugs, gcc-prs, nobody
Synopsis: memory leak for stringstream / ios_base callback cache.
State-Changed-From-To: feedback->open
State-Changed-By: cae
State-Changed-When: Tue Apr 1 09:49:12 2003
State-Changed-Why:
Feedback received.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10276
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
@ 2003-03-31 23:16 Carlo Wood
0 siblings, 0 replies; 6+ messages in thread
From: Carlo Wood @ 2003-03-31 23:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/10276; it has been noted by GNATS.
From: Carlo Wood <carlo@alinoe.com>
To: ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
Date: Tue, 1 Apr 2003 01:13:20 +0200
Just got another mail.
Benjamin Kosnik confirmed it again, apparently it should
be assigned to Jerry, not Loren.
See http://gcc.gnu.org/ml/libstdc++/2003-03/msg00383.html
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libstdc++/10276: memory leak for stringstream / ios_base callback cache.
@ 2003-03-31 17:40 ehrhardt
0 siblings, 0 replies; 6+ messages in thread
From: ehrhardt @ 2003-03-31 17:40 UTC (permalink / raw)
To: carlo, gcc-bugs, gcc-prs, nobody
Synopsis: memory leak for stringstream / ios_base callback cache.
State-Changed-From-To: open->feedback
State-Changed-By: cae
State-Changed-When: Mon Mar 31 17:20:22 2003
State-Changed-Why:
Do you actually see a memory leak? As far as I can see _M_dispose_callbacks()
(called by the ios_base destructor) should free the memory.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10276
^ permalink raw reply [flat|nested] 6+ messages in thread
* libstdc++/10276: memory leak for stringstream / ios_base callback cache.
@ 2003-03-31 13:36 carlo
0 siblings, 0 replies; 6+ messages in thread
From: carlo @ 2003-03-31 13:36 UTC (permalink / raw)
To: gcc-gnats
>Number: 10276
>Category: libstdc++
>Synopsis: memory leak for stringstream / ios_base callback cache.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Mar 31 12:46:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Carlo Wood
>Release: 3.3 branch
>Organization:
>Environment:
i686-gnu-linux
>Description:
The following code snippet leaks memory:
for (int i = 0; i < 1000; ++i)
{
std::ostringstream s;
}
this results in 1000 undeleted allocations that made
with 'new' in respectively ios.cc and basic_ios.tcc
at:
ios.cc:
void
ios_base::register_callback(event_callback __fn, int __index)
{ _M_callbacks = new _Callback_list(__fn, __index, _M_callbacks); }
and
bits/basic_ios.tcc:
if (!pword(0)) {
pword(0) = auto_ptr<__cache_t>(new __cache_t()).release();
register_callback(__cache_t::_S_callback, 0);
}
Can someone please make this high priority?
Its a regression and I really think that it
MUST be fixed before 3.3 is released.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-04-29 16:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-31 23:16 libstdc++/10276: memory leak for stringstream / ios_base callback cache Carlo Wood
-- strict thread matches above, loose matches on Subject: below --
2003-04-29 16:06 bkoz
2003-04-01 9:49 ehrhardt
2003-03-31 23:16 Carlo Wood
2003-03-31 17:40 ehrhardt
2003-03-31 13:36 carlo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).