[Bug c++/12094] New: runtime mem leak in executable, using ostringstream

["j dot beyer at web dot de" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12094

           Summary: runtime mem leak in executable, using ostringstream
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: j dot beyer at web dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu

I think, I found a mem leak - maybe I am wrong.

This simple source:

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

using namespace std;

void f() {
    ostringstream s;
    s << "huhu";
    cout << s.str() << endl;
}
int main(int argc, char* argv[]) {
    int runs = argc==2?atoi(argv[1]):1;
    for(int i=0;i<runs; ++i) {
        f();
    }
}
------------------------------------
compile: g++ main.cpp -g·
valgrind: valgrind -v --leak-check=yes --show-reachable=yes --num-callers=15 ./a
.out 1000

where 1000 is the number of loops you want to try.

compiles and links to a binary that - according to
valgrind - leaks some mem if the loop runs at least
once, thus calls f(). It is not relevant how often
the loop runs. I could reproduce it with any gcc up
to gcc-3.1.1 (have not yet tried CVS-HEAD).

Here is the relvant valgrind output for
0 runs
==26314== LEAK SUMMARY:
==26314==    definitely lost: 16 bytes in 1 blocks.
==26314==    possibly lost:   0 bytes in 0 blocks.
==26314==    still reachable: 64 bytes in 1 blocks.
==26314==         suppressed: 0 bytes in 0 blocks.

1 run
==26342== LEAK SUMMARY:
==26342==    definitely lost: 16 bytes in 1 blocks.
==26342==    possibly lost:   0 bytes in 0 blocks.
==26342==    still reachable: 1024 bytes in 2 blocks.
==26342==         suppressed: 0 bytes in 0 blocks.

1000 runs
==27255== LEAK SUMMARY:
==27255==    definitely lost: 16 bytes in 1 blocks.
==27255==    possibly lost:   0 bytes in 0 blocks.
==27255==    still reachable: 1024 bytes in 2 blocks.
==27255==         suppressed: 0 bytes in 0 blocks.


Since calling f() several times leaks always the same
amount of memory, I am not sure if this has to do with
some static memory that is allocated once (like for the
locale stuff).

Questions:
* could anybody else reproduce this
* is it a leak that may hurt?

    Joerg Beyer