libstdc++/6582: memory leaks in iostream and locale

libstdc++/6582: memory leaks in iostream and locale

[gawrilow]

>Number:         6582
>Category:       libstdc++
>Synopsis:       memory leaks in iostream  and locale
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 06 10:46:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Ewgenij Gawrilow
>Release:        3.0.4
>Organization:
>Environment:
n/a
>Description:
Some static objects created by libstdc++, namely std::cin,
std::cout, std::cerr, std::clog, and the classic locale, are
not destroyed at the program termination. Since they contain data members, such as strings, callback lists, etc., which hold dynamically allocated storage fragments, they look perfectly like memory leaks.

These leaks do not constitute a problem as such; there are,
though, two reasons for eliminating them:

1. of systematical nature: why bother to delete filebufs
belonging to the streams but let other components out

2. of practical nature: when hunting for real memory leaks
in the application using some automated means, be that purify or a self-made drop-in for the STL allocator, these additional leaks really disturb: The allocation
requests do not come at predictable moments, so that it's
rather difficult to filter them out.
>How-To-Repeat:

>Fix:
For streams, the fix is rather trivial. The attached patch is based on the source code as included in gcc 3.0.4 distribution, but can be easily applied to the actual CVS branches.

However, I didn't dare to write a patch for the classic locale, as I saw the substantial changes between the last
versions of locale.cc. It seems being substantially reworked right now. I hope, the maintainer finds a few minutes to
build in the destructor too.

Thank you in advance!
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gcc-3.0.4-patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gcc-3.0.4-patch"

LS0tIGdjYy0zLjAuNC9saWJzdGRjKystdjMvc3JjL2lvcy5jY34JV2VkIEp1biAgNiAwMzozOTow
MSAyMDAxCisrKyBnY2MtMy4wLjQvbGlic3RkYysrLXYzL3NyYy9pb3MuY2MJRnJpIE1heSAgMyAy
MDoyMjowNSAyMDAyCkBAIC0xODQsNiArMTg0LDEwIEBACiAgICAgYnVmX2NvdXQufmZpbGVidWYo
KTsKICAgICBidWZfY2luLn5maWxlYnVmKCk7CiAgICAgYnVmX2NlcnIufmZpbGVidWYoKTsKKyAg
ICBjb3V0Ln5vc3RyZWFtKCk7CisgICAgY2luLn5pc3RyZWFtKCk7CisgICAgY2Vyci5+b3N0cmVh
bSgpOworICAgIGNsb2cufm9zdHJlYW0oKTsKICNpZmRlZiBfR0xJQkNQUF9VU0VfV0NIQVJfVAog
ICAgIHdjb3V0LmZsdXNoKCk7CiAgICAgd2NlcnIuZmx1c2goKTsKQEAgLTE5MSw2ICsxOTUsMTAg
QEAKICAgICBidWZfd2NvdXQufndmaWxlYnVmKCk7CiAgICAgYnVmX3djaW4ufndmaWxlYnVmKCk7
CiAgICAgYnVmX3djZXJyLn53ZmlsZWJ1ZigpOworICAgIHdjb3V0Ln53b3N0cmVhbSgpOworICAg
IHdjaW4ufndpc3RyZWFtKCk7CisgICAgd2NlcnIufndvc3RyZWFtKCk7CisgICAgd2Nsb2cufndv
c3RyZWFtKCk7CiAjZW5kaWYKICAgfQo=

Re: libstdc++/6582: memory leaks in iostream and locale

[bkoz]

Synopsis: memory leaks in iostream  and locale

State-Changed-From-To: feedback->closed
State-Changed-By: bkoz
State-Changed-When: Fri May 17 03:08:23 2002
State-Changed-Why:
    Fixed

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6582

Re: libstdc++/6582: memory leaks in iostream and locale

[bkoz]

Synopsis: memory leaks in iostream  and locale

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Wed May 15 07:42:33 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Wed May 15 07:42:33 2002
State-Changed-Why:
    
    Please consider using the soon-to-be released 3.1.0, or mainline 3.2 sources. Both have revamped allocation strategies from the code you are using, and neither have the problems you are reporting. I've checked with valgrind and the current sources, and everything looks ok except for one issue with the underlying "C" locale information, which valgrind displays as a 16 and a 64 byte leak. These are to be expected. 
    
    Before the allocation tuning happened, there were 53 such issues. 
    
    -benjamin

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6582