Memory leak in strstream in Dinkum libs???

There seems to be a problem in the Dinkum implementation of strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under QNX4).

Perhaps I am missing some subtlety or else it sure looks looks like a bug in
the library.

And yes, I know that strstream is deprecated and stringstream should be used
instead. That is the solution we are currently using (it doesn’t leak) but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h>

#include
#include
#include

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}

On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
<ruzz@NoSpamPlease.ruzz.com> wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1) xyz(param)” mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under QNX4).

Perhaps I am missing some subtlety or else it sure looks looks like a bug in
the library.

And yes, I know that strstream is deprecated and stringstream should be used
instead. That is the solution we are currently using (it doesn’t leak) but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}

I’m sorry, your questions don’t make a lot of sense to me.

string(buf) is what is returned by the function. A temporary string object
will be created and returned on the stack. Its destructor will get called
after it has been used by the << operator in the main while() loop.

I believe this is very straightforward and correct C++ code. There is no
mystery in my mind as to what should happen. Of course I am open to
correction :slight_smile:

Rob Rutherford

“Andrzej Kocon” <ako@box43.gnet.pl> wrote in message
news:3d3316c9.71873@inn.qnx.com

On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
ruzz@NoSpamPlease.ruzz.com> > wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1) xyz(param)” mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under QNX4).

Perhaps I am missing some subtlety or else it sure looks looks like a bug
in
the library.

And yes, I know that strstream is deprecated and stringstream should be
used
instead. That is the solution we are currently using (it doesn’t leak)
but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}
\

Just for chuckles, try running the loop for a set amount of time and see if
the memory is released once you pass out of the while loop scope.

Kris

“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:agvmta$3nm$1@inn.qnx.com

I’m sorry, your questions don’t make a lot of sense to me.

string(buf) is what is returned by the function. A temporary string object
will be created and returned on the stack. Its destructor will get called
after it has been used by the << operator in the main while() loop.

I believe this is very straightforward and correct C++ code. There is no
mystery in my mind as to what should happen. Of course I am open to
correction > :slight_smile:

Rob Rutherford

“Andrzej Kocon” <> ako@box43.gnet.pl> > wrote in message
news:> 3d3316c9.71873@inn.qnx.com> …
On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
ruzz@NoSpamPlease.ruzz.com> > wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1) xyz(param)” mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under QNX4).

Perhaps I am missing some subtlety or else it sure looks looks like a
bug
in
the library.

And yes, I know that strstream is deprecated and stringstream should be
used
instead. That is the solution we are currently using (it doesn’t leak)
but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}


\

Curious enough to try it myself. The memory leaked is on the heap and it
definitely isn’t getting freed, even outside of the while loop scope. I’ll
investigate further.

cheers,

Kris

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ah12ck$6n6$1@nntp.qnx.com

Just for chuckles, try running the loop for a set amount of time and see
if
the memory is released once you pass out of the while loop scope.

Kris

“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > wrote in message
news:agvmta$3nm$> 1@inn.qnx.com> …
I’m sorry, your questions don’t make a lot of sense to me.

string(buf) is what is returned by the function. A temporary string
object
will be created and returned on the stack. Its destructor will get
called
after it has been used by the << operator in the main while() loop.

I believe this is very straightforward and correct C++ code. There is no
mystery in my mind as to what should happen. Of course I am open to
correction > :slight_smile:

Rob Rutherford

“Andrzej Kocon” <> ako@box43.gnet.pl> > wrote in message
news:> 3d3316c9.71873@inn.qnx.com> …
On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
ruzz@NoSpamPlease.ruzz.com> > wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1) xyz(param)” mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of
strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under QNX4).

Perhaps I am missing some subtlety or else it sure looks looks like a
bug
in
the library.

And yes, I know that strstream is deprecated and stringstream should
be
used
instead. That is the solution we are currently using (it doesn’t
leak)
but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}




\

It looks like the fact that it’s deprecated means it’s probably not a high
priority to fix. This is unfortunate but we don’t control what comes out of
Dinkumware so if you absolutely have to get it fixed, then you’ll need to
talk to a support person about getting the work done.

cheers,

Kris

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ah12pt$71s$1@nntp.qnx.com

Curious enough to try it myself. The memory leaked is on the heap and it
definitely isn’t getting freed, even outside of the while loop scope.
I’ll
investigate further.

cheers,

Kris

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ah12ck$6n6$> 1@nntp.qnx.com> …
Just for chuckles, try running the loop for a set amount of time and see
if
the memory is released once you pass out of the while loop scope.

Kris

“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > wrote in message
news:agvmta$3nm$> 1@inn.qnx.com> …
I’m sorry, your questions don’t make a lot of sense to me.

string(buf) is what is returned by the function. A temporary string
object
will be created and returned on the stack. Its destructor will get
called
after it has been used by the << operator in the main while() loop.

I believe this is very straightforward and correct C++ code. There is
no
mystery in my mind as to what should happen. Of course I am open to
correction > :slight_smile:

Rob Rutherford

“Andrzej Kocon” <> ako@box43.gnet.pl> > wrote in message
news:> 3d3316c9.71873@inn.qnx.com> …
On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
ruzz@NoSpamPlease.ruzz.com> > wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1) xyz(param)”
mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of
strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under QNX4).

Perhaps I am missing some subtlety or else it sure looks looks like
a
bug
in
the library.

And yes, I know that strstream is deprecated and stringstream
should
be
used
instead. That is the solution we are currently using (it doesn’t
leak)
but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}






\

Kris,

Thanks for looking into this and confirming that it is indeed a bug .

While strstream is “deprecated” it is still part of the C++ Standard. I
would have thought that Dinkumware would be pretty keen to get this
reported/fixed. At the very least you should get it added to the release
notes/known problems.It took a long time for me to track this down as the
source of our mystery memory leak - normally the system libraries are the
least likely culprit.

Anyway the main issue for us was finding the source of the leak and finding
a workaround (sstream).

Robert.

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ah1a9a$cij$1@nntp.qnx.com

It looks like the fact that it’s deprecated means it’s probably not a high
priority to fix. This is unfortunate but we don’t control what comes out
of
Dinkumware so if you absolutely have to get it fixed, then you’ll need to
talk to a support person about getting the work done.

cheers,

Kris

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ah12pt$71s$> 1@nntp.qnx.com> …
Curious enough to try it myself. The memory leaked is on the heap and
it
definitely isn’t getting freed, even outside of the while loop scope.
I’ll
investigate further.

cheers,

Kris

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ah12ck$6n6$> 1@nntp.qnx.com> …
Just for chuckles, try running the loop for a set amount of time and
see
if
the memory is released once you pass out of the while loop scope.

Kris

“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > wrote in message
news:agvmta$3nm$> 1@inn.qnx.com> …
I’m sorry, your questions don’t make a lot of sense to me.

string(buf) is what is returned by the function. A temporary string
object
will be created and returned on the stack. Its destructor will get
called
after it has been used by the << operator in the main while() loop.

I believe this is very straightforward and correct C++ code. There
is
no
mystery in my mind as to what should happen. Of course I am open
to
correction > :slight_smile:

Rob Rutherford

“Andrzej Kocon” <> ako@box43.gnet.pl> > wrote in message
news:> 3d3316c9.71873@inn.qnx.com> …
On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
ruzz@NoSpamPlease.ruzz.com> > wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1) xyz(param)”
mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of
strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under
QNX4).

Perhaps I am missing some subtlety or else it sure looks looks
like
a
bug
in
the library.

And yes, I know that strstream is deprecated and stringstream
should
be
used
instead. That is the solution we are currently using (it doesn’t
leak)
but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}








\

Absolutely. Our Dinkum contact is going to let them know about it and we’ll
be sure to make a note in the appropriate doc. It may be that Dinkum
doesn’t know about it and will want to fix it right away.

cheers,

Kris

“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:ah29tf$4s1$1@inn.qnx.com

Kris,

Thanks for looking into this and confirming that it is indeed a bug .

While strstream is “deprecated” it is still part of the C++ Standard. I
would have thought that Dinkumware would be pretty keen to get this
reported/fixed. At the very least you should get it added to the release
notes/known problems.It took a long time for me to track this down as the
source of our mystery memory leak - normally the system libraries are the
least likely culprit.

Anyway the main issue for us was finding the source of the leak and
finding
a workaround (sstream).

Robert.

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ah1a9a$cij$> 1@nntp.qnx.com> …
It looks like the fact that it’s deprecated means it’s probably not a
high
priority to fix. This is unfortunate but we don’t control what comes
out
of
Dinkumware so if you absolutely have to get it fixed, then you’ll need
to
talk to a support person about getting the work done.

cheers,

Kris

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ah12pt$71s$> 1@nntp.qnx.com> …
Curious enough to try it myself. The memory leaked is on the heap and
it
definitely isn’t getting freed, even outside of the while loop scope.
I’ll
investigate further.

cheers,

Kris

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ah12ck$6n6$> 1@nntp.qnx.com> …
Just for chuckles, try running the loop for a set amount of time and
see
if
the memory is released once you pass out of the while loop scope.

Kris

“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > wrote in message
news:agvmta$3nm$> 1@inn.qnx.com> …
I’m sorry, your questions don’t make a lot of sense to me.

string(buf) is what is returned by the function. A temporary
string
object
will be created and returned on the stack. Its destructor will get
called
after it has been used by the << operator in the main while()
loop.

I believe this is very straightforward and correct C++ code. There
is
no
mystery in my mind as to what should happen. Of course I am open
to
correction > :slight_smile:

Rob Rutherford

“Andrzej Kocon” <> ako@box43.gnet.pl> > wrote in message
news:> 3d3316c9.71873@inn.qnx.com> …
On Mon, 15 Jul 2002 17:54:51 +1000, “Robert Rutherford”
ruzz@NoSpamPlease.ruzz.com> > wrote:

What is the scope of the “string(buf)” object in the leak()
function? If local, it is illegal to pass it ouside, although
the
program might work because the memory released by the destructor
remains intact. If global, then what would “while (1)
xyz(param)”
mean
(with xyz being a class name)? Would it be one single object
initialized many times? Why should we expect the constructor to
release “previously” allocated memory (if any)?

ako

There seems to be a problem in the Dinkum implementation of
strstream.

The following sample program leaks like a sieve with Dinkum.
It doesn’t leak with the GNU (GCC) Libs or Watcom/STL (under
QNX4).

Perhaps I am missing some subtlety or else it sure looks looks
like
a
bug
in
the library.

And yes, I know that strstream is deprecated and stringstream
should
be
used
instead. That is the solution we are currently using (it
doesn’t
leak)
but
it means we have a lot of legacy code to fix.

We are using 6.2.

Rob Rutherford
Ruzz Technology

=====================================================
// Test strstream for leaks
// Build with “QCC leak.cc -o leak”

#include <unistd.h

#include <string
#include <iostream
#include <strstream

using namespace std;

string leaker( void ) {

char buf[80];
ostrstream bufstream( buf, sizeof(buf) );

bufstream << “Hello” << ends;

return string(buf);

}

int main( int argc, char *argv[] ) {

while(1) {

cout << leaker() << endl;
usleep(500);

}

}










\

Kris Warkentin <kewarken@qnx.com> wrote:
: Absolutely. Our Dinkum contact is going to let them know about it and we’ll
: be sure to make a note in the appropriate doc. It may be that Dinkum
: doesn’t know about it and will want to fix it right away.

I’ll add this to our release notes.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems