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.
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 > 
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);
}
}
\