Bug 128467 - memory leak when allocating string objects
memory leak when allocating string objects
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2004-07-23 06:16 EDT by Edward Pilipczuk
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-05 16:53:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Edward Pilipczuk 2004-07-23 06:16:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
when allocating new string object small chunk of memory is allocated
by the libstdc++.so.5 and never freed.
The small test program (presented in additional information section) 
shows that behaviour. I used mtrace to check memory allocations,
results are shown in Actual Resultes after Steps to Reproduce.

Strings constructed with int-2-string conversions I used in logger
class in a multithreaded program (nptl) and I have here huge memory

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.compile tst program (see Additional Information) by the command
   $ g++ -g -o tst -Wall -ansi -pedantic tst.cpp
2.setup environment variable for mtrace
   $ export MALLOC_TRACE=~/tr.txt
3.run tst program
4.examine tr.txt file and output of mtrace perl utility:
   $ mtrace tst tr.txt

Actual Results:  tr.txt file contains:
= Start
@ ./tst:[0x804a53d] + 0x915a378 0x1
@ /usr/lib/libstdc++.so.5:(_Znwj+0x2e)[0x9893ae] + 0x915a388 0x470
@ /usr/lib/libstdc++.so.5:(_Znwj+0x2e)[0x9893ae] + 0x915a800 0x280 
<<<- here is the problem
@ /usr/lib/libstdc++.so.5:(_ZdlPv+0x23)[0x987dd3] - 0x915a388
@ ./tst:[0x804a59e] + 0x915a388 0x1
@ /usr/lib/libstdc++.so.5:(_Znwj+0x2e)[0x9893ae] + 0x915aa88 0x470
@ /usr/lib/libstdc++.so.5:(_ZdlPv+0x23)[0x987dd3] - 0x915aa88
@ /usr/lib/libstdc++.so.5:(_Znwj+0x2e)[0x9893ae] + 0x915aa88 0x470
@ /usr/lib/libstdc++.so.5:(_ZdlPv+0x23)[0x987dd3] - 0x915aa88

Expected Results:  release all memory when string object is destroyed.

Additional info:

// memory leak in strings --> test program

#include <mcheck.h>		// for mtrace utility

#include <string>
#include <sstream>
#include <iostream>

using namespace std;

template< class T >		// conversion of anything to string
inline std::string _2string( const T& _t ) {
  ostringstream os;
  os << _t;
  return( os.str() );

class version {
  unsigned ver:8,		// version number: 0-255
    rel:8,			// maintenance release: 0-255
    patch:16;			// patchlevel: 0-16355
  version( int, int, int );
  string vstr;			// version string in a form of "ver.rel.patch"

// methods of class version
version::version( int v, int r, int p )
  ver   = v  & 0x000000FF;
  rel   = r  & 0x000000FF;
  patch = p  & 0x0000FFFF;
  malloc(1);			// isolation of the problem
  vstr += _2string(v);
  malloc(1);			// isolation of the problem
  vstr +=  string(".");
  vstr += _2string(r);
  vstr +=  string(".");
  vstr += _2string(p);

int main()
  class version vers( 0, 0, 99 );
  cerr << "TEST version " << vers.vstr << endl; 
Comment 1 Ulrich Drepper 2004-09-30 05:01:40 EDT
This has nothing to do with glibc.  Reassign to gcc.
Comment 2 Benjamin Kosnik 2004-10-01 10:33:59 EDT
This is a known issue with the default allocator in gcc-3.[23].x.
These limitations have been removed for 3.4.x series.

There is a work-around, however: use

basic_string<char_type, std::char_traits<char_type>, __new_alloc<char> >

instead of


Comment 3 Richard Henderson 2004-10-05 16:53:14 EDT
Fixed for gcc 3.4.

Note You need to log in before you can comment on or make changes to this bug.