Memory leak in fstream(int fd)

QNX Newsgroups (Archives) qnx.development_tools
1

We’ve discovered a memory leak when constructing an fstream from a file
descriptor. Because fstream does buffered IO, it attempts to create a C
stream by issuing a call to fdopen(). During destruction of the create
fstream, any bufferes allocated during file IO operations are not
deallocated, as fclose() is not (and cannot) be called on the C stream.

The following example will illustrate the leak:

#include
#include
#include
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

using namespace std;

void WriteData( ostream &stream );
void write_stuff( int fd );

int main(int argc, char *argv[])
{
int fd = open( “/TestStream.txt”, O_CREAT | O_RDWR );

while( true )
{
write_stuff( fd );
delay( 20 );
}

return EXIT_SUCCESS;
}

void
write_stuff( int fd )
{
ofstream myStream( fd );

if( myStream.is_open() )
cout << “File openned” << endl;
WriteData( myStream );

}

void
WriteData( ostream &stream )
{
char buffer[120];

stream.write( buffer, 120 );
stream.flush();
}

2

On Fri, 18 Nov 2005 13:23:51 -0400, RIchard Doucet wrote:

We’ve discovered a memory leak when constructing an fstream from a file
descriptor. Because fstream does buffered IO, it attempts to create a C
stream by issuing a call to fdopen(). During destruction of the create
fstream, any bufferes allocated during file IO operations are not
deallocated, as fclose() is not (and cannot) be called on the C stream.

The following example will illustrate the leak:

…
ofstream myStream( fd );

I presume you’re talking QNX4 here.

In Neutrino (and AFAIK any standards-compliant C++ implementation) there is
no constructor for an ofstream which lets you pass in an existing file
descriptor. The reason for this is largely to avoid exactly this kind of
resource leak.

Maybe you can wrap the fstream in a derived class that takes care of the
resource management for you?

Rob Rutherford
Ruzz Technology

3

No, this problem is under RTP/Dinkum. Works fine under QNX 4/HP STL.

“Robert Rutherford” <mail@NoSpamPlease.ruzz.com> wrote in message
news:10fnngowddebu.l8b5ymtaqg0q.dlg@40tude.net…

On Fri, 18 Nov 2005 13:23:51 -0400, RIchard Doucet wrote:
We’ve discovered a memory leak when constructing an fstream from a file
descriptor. Because fstream does buffered IO, it attempts to create a C
stream by issuing a call to fdopen(). During destruction of the create
fstream, any bufferes allocated during file IO operations are not
deallocated, as fclose() is not (and cannot) be called on the C stream.

The following example will illustrate the leak:

…
ofstream myStream( fd );


I presume you’re talking QNX4 here.

In Neutrino (and AFAIK any standards-compliant C++ implementation) there
is
no constructor for an ofstream which lets you pass in an existing file
descriptor. The reason for this is largely to avoid exactly this kind of
resource leak.

Maybe you can wrap the fstream in a derived class that takes care of the
resource management for you?

Rob Rutherford
Ruzz Technology

4

ping…

“RIchard Doucet” <doucetr@DONTaeclSPAM.caME> wrote in message
news:dlsmus$k99$1@inn.qnx.com…

No, this problem is under RTP/Dinkum. Works fine under QNX 4/HP STL.

“Robert Rutherford” <> mail@NoSpamPlease.ruzz.com> > wrote in message
news:> 10fnngowddebu.l8b5ymtaqg0q.dlg@40tude.net> …
On Fri, 18 Nov 2005 13:23:51 -0400, RIchard Doucet wrote:
We’ve discovered a memory leak when constructing an fstream from a file
descriptor. Because fstream does buffered IO, it attempts to create a C
stream by issuing a call to fdopen(). During destruction of the create
fstream, any bufferes allocated during file IO operations are not
deallocated, as fclose() is not (and cannot) be called on the C stream.

The following example will illustrate the leak:

…
ofstream myStream( fd );


I presume you’re talking QNX4 here.

In Neutrino (and AFAIK any standards-compliant C++ implementation) there
is
no constructor for an ofstream which lets you pass in an existing file
descriptor. The reason for this is largely to avoid exactly this kind of
resource leak.

Maybe you can wrap the fstream in a derived class that takes care of the
resource management for you?

Rob Rutherford
Ruzz Technology