You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2006/12/11 17:31:21 UTC
[jira] Created: (STDCXX-308) filebuf dtor doesn't close fd after
exception
filebuf dtor doesn't close fd after exception
---------------------------------------------
Key: STDCXX-308
URL: http://issues.apache.org/jira/browse/STDCXX-308
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Assigned To: Martin Sebor
-------- Original Message --------
Subject: Re: aCC 3.70 -AA fd's close not being called.
Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
From: Dennis Handly <dh...@cup.hp.com>
To: sebor@roguewave.com
CC: Boris.Gubenko@hp.com, al.simons@hp.com, dhandly@cup.hp.com
It appears this problem is still in the apache code:
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
It seems to violate 27.8.1.3(6), which says it always "finally" calls
"as if" fclose(3). And returns an error if any calls fail.
================================================================
>From: "Levie, Barry" <ba...@hp.com>
Date: Thu, 7 Dec 2006 15:36:33 -0000
Subject: aCC 3.70 -AA fd's close not being called.
I am not sure if this exactly represents the problem the customer is
having as I am still waiting for more details (versions/test case etc
etc). However this could be close and I think it shows a problem.
Why does the ofstream destructor not close the file descriptor when its
called after its thrown an exception for "out of disk space".
This aCC 3.70 -AA example shows an ever increasing number of open file
descriptors in glance
# what /usr/lib/libstd_v2.2:
HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
#include <iostream>
#include <fstream>
#include <string.h>
using namespace std;
struct dummy {
dummy() { cout << "\ndummy created \n" ;}
~dummy() { cout << "\ndummy deleted \n"; }
};
void bar() {
char buf[1024*1024];
memset(buf,'A',1024*1024);
buf[1024*1024 -1] = 0;
ofstream of;
dummy df;
of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
try {
of.open("/home/test.txt"); // this is on a volume that is nearly full.
while(1) {
of << buf;
}
}
catch(ofstream::failure& e) {
cout << "\nException write/file";
}
}
int main () {
while(1) bar();
}
# ./a.out
dummy created
msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
(1 block extent)
Exception write/file
dummy deleted
....
Glance output shows
D File Name Type Mode Count Offset
---------------------------------------------------
0 /dev/pts/ta stream rd/wr 6 333822
1 /dev/pts/ta stream rd/wr 6 333822
2 /dev/pts/ta stream rd/wr 6 333822
3 /home/test.txt reg write 1 101957632
4 /home/test.txt reg write 1 101957632
5 /home/test.txt reg write 1 101957632
...
================================================================
>From: Dennis Handly <dh...@cup.hp.com>
Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
To: acxx@cup.hp.com, barry.levie@hp.com
Subject: Re: aCC 3.70 -AA fd's close not being called.
>From: "Levie, Barry" <ba...@hp.com>
>I am not sure if this exactly represents the problem the customer is
>having as I am still waiting for more details (versions/test case etc
>etc). However this could be close and I think it shows a problem.
>Why does the ofstream destructor not close the file descriptor when its
>called after its thrown an exception for "out of disk space".
A highly modified version works for me.
And it isn't closed on the throw but by falling off the bar body.
>This aCC 3.70 -AA example shows an ever increasing number of open file
>descriptors in glance
Hmm.
># what /usr/lib/libstd_v2.2:
> HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
This obsolete version isn't supported.
Here is what I have and it shows close being called after I throw.
I've manually modified the write return to -1 and that throws and is caught.
(The debugger was broken and it didn't really happen. )-:
#include <iostream>
#include <fstream>
#include <string.h>
#include <stdio.h>
using namespace std;
struct dummy {
dummy() { fprintf(stdout, "dummy created\n"); fflush(stdout); }
~dummy() { fprintf(stdout, "dummy deleted\n"); fflush(stdout); }
};
extern "C" int _close(int fd);
extern "C" int close(int fd) {
if (fd > STDERR_FILENO) {
fprintf(stdout, "close(%d)\n", fd);
fflush(stdout);
}
return _close(fd);
}
char buf[1024];
void bar() {
ofstream of;
dummy df;
of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
try {
of.open("test.txt"); // this is on a volume that is nearly full.
fprintf(stdout, "FD = %d\n", of.rdbuf()->fd());
fflush(stdout);
for (int i = 0; i < 2; ++i)
of << buf;
throw ios_base::failure();
}
catch(ofstream::failure &e) {
fprintf(stdout, "Exception write/file\n");
fflush(stdout);
}
}
int main() {
memset(buf,'A',sizeof(buf));
buf[sizeof(buf)-1] = '\0';
int i;
for (i = 0; i < 10; ++i)
bar();
}
Ah, it's catch 22. When it destroys ofstream it calls close, which calls
overflow which calls _C_write which calls write which gets an error and
then returns before closing.
It seems it is working as designed be RW.
But this seems to violate 27.8.1.3(6), which says it always calls
fclose(3).
File a CR.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (STDCXX-308) [LWG #622] std::filebuf dtor doesn't
close fd after exception
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-308:
--------------------------------
Fix Version/s: 4.2.1
Summary: [LWG #622] std::filebuf dtor doesn't close fd after exception (was: filebuf dtor doesn't close fd after exception)
Scheduled for 4.2.1.
> [LWG #622] std::filebuf dtor doesn't close fd after exception
> -------------------------------------------------------------
>
> Key: STDCXX-308
> URL: https://issues.apache.org/jira/browse/STDCXX-308
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
> Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Fix For: 4.2.1
>
>
> -------- Original Message --------
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
> From: Dennis Handly <dh...@cup.hp.com>
> To: sebor@roguewave.com
> CC: Boris.Gubenko@hp.com, al.simons@hp.com, dhandly@cup.hp.com
> It appears this problem is still in the apache code:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
> It seems to violate 27.8.1.3(6), which says it always "finally" calls
> "as if" fclose(3). And returns an error if any calls fail.
> ================================================================
> >From: "Levie, Barry" <ba...@hp.com>
> Date: Thu, 7 Dec 2006 15:36:33 -0000
> Subject: aCC 3.70 -AA fd's close not being called.
> I am not sure if this exactly represents the problem the customer is
> having as I am still waiting for more details (versions/test case etc
> etc). However this could be close and I think it shows a problem.
> Why does the ofstream destructor not close the file descriptor when its
> called after its thrown an exception for "out of disk space".
> This aCC 3.70 -AA example shows an ever increasing number of open file
> descriptors in glance
> # what /usr/lib/libstd_v2.2:
> HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> #include <iostream>
> #include <fstream>
> #include <string.h>
> using namespace std;
> struct dummy {
> dummy() { cout << "\ndummy created \n" ;}
> ~dummy() { cout << "\ndummy deleted \n"; }
> };
> void bar() {
> char buf[1024*1024];
> memset(buf,'A',1024*1024);
> buf[1024*1024 -1] = 0;
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("/home/test.txt"); // this is on a volume that is nearly full.
> while(1) {
> of << buf;
> }
> }
> catch(ofstream::failure& e) {
> cout << "\nException write/file";
> }
> }
> int main () {
> while(1) bar();
> }
> # ./a.out
> dummy created
> msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
> (1 block extent)
> Exception write/file
> dummy deleted
> ....
> Glance output shows
> D File Name Type Mode Count Offset
> ---------------------------------------------------
> 0 /dev/pts/ta stream rd/wr 6 333822
> 1 /dev/pts/ta stream rd/wr 6 333822
> 2 /dev/pts/ta stream rd/wr 6 333822
> 3 /home/test.txt reg write 1 101957632
> 4 /home/test.txt reg write 1 101957632
> 5 /home/test.txt reg write 1 101957632
> ...
> ================================================================
> >From: Dennis Handly <dh...@cup.hp.com>
> Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
> To: acxx@cup.hp.com, barry.levie@hp.com
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> >From: "Levie, Barry" <ba...@hp.com>
> >I am not sure if this exactly represents the problem the customer is
> >having as I am still waiting for more details (versions/test case etc
> >etc). However this could be close and I think it shows a problem.
> >Why does the ofstream destructor not close the file descriptor when its
> >called after its thrown an exception for "out of disk space".
> A highly modified version works for me.
> And it isn't closed on the throw but by falling off the bar body.
> >This aCC 3.70 -AA example shows an ever increasing number of open file
> >descriptors in glance
> Hmm.
> ># what /usr/lib/libstd_v2.2:
> > HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> This obsolete version isn't supported.
> Here is what I have and it shows close being called after I throw.
> I've manually modified the write return to -1 and that throws and is caught.
> (The debugger was broken and it didn't really happen. )-:
> #include <iostream>
> #include <fstream>
> #include <string.h>
> #include <stdio.h>
> using namespace std;
> struct dummy {
> dummy() { fprintf(stdout, "dummy created\n"); fflush(stdout); }
> ~dummy() { fprintf(stdout, "dummy deleted\n"); fflush(stdout); }
> };
> extern "C" int _close(int fd);
> extern "C" int close(int fd) {
> if (fd > STDERR_FILENO) {
> fprintf(stdout, "close(%d)\n", fd);
> fflush(stdout);
> }
> return _close(fd);
> }
> char buf[1024];
> void bar() {
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("test.txt"); // this is on a volume that is nearly full.
> fprintf(stdout, "FD = %d\n", of.rdbuf()->fd());
> fflush(stdout);
> for (int i = 0; i < 2; ++i)
> of << buf;
> throw ios_base::failure();
> }
> catch(ofstream::failure &e) {
> fprintf(stdout, "Exception write/file\n");
> fflush(stdout);
> }
> }
> int main() {
> memset(buf,'A',sizeof(buf));
> buf[sizeof(buf)-1] = '\0';
> int i;
> for (i = 0; i < 10; ++i)
> bar();
> }
> Ah, it's catch 22. When it destroys ofstream it calls close, which calls
> overflow which calls _C_write which calls write which gets an error and
> then returns before closing.
> It seems it is working as designed be RW.
> But this seems to violate 27.8.1.3(6), which says it always calls
> fclose(3).
> File a CR.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-308) [LWG #622] std::filebuf dtor doesn't
close fd after exception
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-308:
--------------------------------
Severity: Incorrect Behavior
Affects Version/s: 4.1.4
4.2.0
This affects all released versions.
> [LWG #622] std::filebuf dtor doesn't close fd after exception
> -------------------------------------------------------------
>
> Key: STDCXX-308
> URL: https://issues.apache.org/jira/browse/STDCXX-308
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
> Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: all
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Fix For: 4.2.1
>
>
> -------- Original Message --------
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
> From: Dennis Handly <dh...@cup.hp.com>
> To: sebor@roguewave.com
> CC: Boris.Gubenko@hp.com, al.simons@hp.com, dhandly@cup.hp.com
> It appears this problem is still in the apache code:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
> It seems to violate 27.8.1.3(6), which says it always "finally" calls
> "as if" fclose(3). And returns an error if any calls fail.
> ================================================================
> >From: "Levie, Barry" <ba...@hp.com>
> Date: Thu, 7 Dec 2006 15:36:33 -0000
> Subject: aCC 3.70 -AA fd's close not being called.
> I am not sure if this exactly represents the problem the customer is
> having as I am still waiting for more details (versions/test case etc
> etc). However this could be close and I think it shows a problem.
> Why does the ofstream destructor not close the file descriptor when its
> called after its thrown an exception for "out of disk space".
> This aCC 3.70 -AA example shows an ever increasing number of open file
> descriptors in glance
> # what /usr/lib/libstd_v2.2:
> HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> #include <iostream>
> #include <fstream>
> #include <string.h>
> using namespace std;
> struct dummy {
> dummy() { cout << "\ndummy created \n" ;}
> ~dummy() { cout << "\ndummy deleted \n"; }
> };
> void bar() {
> char buf[1024*1024];
> memset(buf,'A',1024*1024);
> buf[1024*1024 -1] = 0;
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("/home/test.txt"); // this is on a volume that is nearly full.
> while(1) {
> of << buf;
> }
> }
> catch(ofstream::failure& e) {
> cout << "\nException write/file";
> }
> }
> int main () {
> while(1) bar();
> }
> # ./a.out
> dummy created
> msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
> (1 block extent)
> Exception write/file
> dummy deleted
> ....
> Glance output shows
> D File Name Type Mode Count Offset
> ---------------------------------------------------
> 0 /dev/pts/ta stream rd/wr 6 333822
> 1 /dev/pts/ta stream rd/wr 6 333822
> 2 /dev/pts/ta stream rd/wr 6 333822
> 3 /home/test.txt reg write 1 101957632
> 4 /home/test.txt reg write 1 101957632
> 5 /home/test.txt reg write 1 101957632
> ...
> ================================================================
> >From: Dennis Handly <dh...@cup.hp.com>
> Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
> To: acxx@cup.hp.com, barry.levie@hp.com
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> >From: "Levie, Barry" <ba...@hp.com>
> >I am not sure if this exactly represents the problem the customer is
> >having as I am still waiting for more details (versions/test case etc
> >etc). However this could be close and I think it shows a problem.
> >Why does the ofstream destructor not close the file descriptor when its
> >called after its thrown an exception for "out of disk space".
> A highly modified version works for me.
> And it isn't closed on the throw but by falling off the bar body.
> >This aCC 3.70 -AA example shows an ever increasing number of open file
> >descriptors in glance
> Hmm.
> ># what /usr/lib/libstd_v2.2:
> > HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> This obsolete version isn't supported.
> Here is what I have and it shows close being called after I throw.
> I've manually modified the write return to -1 and that throws and is caught.
> (The debugger was broken and it didn't really happen. )-:
> #include <iostream>
> #include <fstream>
> #include <string.h>
> #include <stdio.h>
> using namespace std;
> struct dummy {
> dummy() { fprintf(stdout, "dummy created\n"); fflush(stdout); }
> ~dummy() { fprintf(stdout, "dummy deleted\n"); fflush(stdout); }
> };
> extern "C" int _close(int fd);
> extern "C" int close(int fd) {
> if (fd > STDERR_FILENO) {
> fprintf(stdout, "close(%d)\n", fd);
> fflush(stdout);
> }
> return _close(fd);
> }
> char buf[1024];
> void bar() {
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("test.txt"); // this is on a volume that is nearly full.
> fprintf(stdout, "FD = %d\n", of.rdbuf()->fd());
> fflush(stdout);
> for (int i = 0; i < 2; ++i)
> of << buf;
> throw ios_base::failure();
> }
> catch(ofstream::failure &e) {
> fprintf(stdout, "Exception write/file\n");
> fflush(stdout);
> }
> }
> int main() {
> memset(buf,'A',sizeof(buf));
> buf[sizeof(buf)-1] = '\0';
> int i;
> for (i = 0; i < 10; ++i)
> bar();
> }
> Ah, it's catch 22. When it destroys ofstream it calls close, which calls
> overflow which calls _C_write which calls write which gets an error and
> then returns before closing.
> It seems it is working as designed be RW.
> But this seems to violate 27.8.1.3(6), which says it always calls
> fclose(3).
> File a CR.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-308) filebuf dtor doesn't close fd after
exception
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/STDCXX-308?page=comments#action_12457394 ]
Martin Sebor commented on STDCXX-308:
-------------------------------------
-------- Original Message --------
Subject: Re: aCC 3.70 -AA fd's close not being called.
Date: Fri, 08 Dec 2006 16:39:27 -0700
From: Martin Sebor <se...@roguewave.com>
Organization: Rogue Wave Software
To: Dennis Handly <dh...@cup.hp.com>
CC: Boris.Gubenko@hp.com, al.simons@hp.com
References: <20...@hpcll183.hp.com>
Attached is the only response I got so far. Unless someone loudly
objects I will write up an issue and propose to change the spec
to require the behavior Nathan outlined.
Martin
Dennis Handly wrote:
>>From: Martin Sebor <se...@roguewave.com>
>>I don't think the text is clear about close() being required to call
>>fclose() even if overflow() fails (or throws).
>
>
> I thought it quite clear when it said "finally".
>
>
>>Otherwise it should leave it open so that the caller can fix the problem
>>and not lose data.
>
>
> The user should use flush instead of close.
>
>
>>... specify this behavior explicitly. Let me raise it on the reflector.
>
> Martin
>
> Thanks.
> filebuf dtor doesn't close fd after exception
> ---------------------------------------------
>
> Key: STDCXX-308
> URL: http://issues.apache.org/jira/browse/STDCXX-308
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
> Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Assigned To: Martin Sebor
>
> -------- Original Message --------
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
> From: Dennis Handly <dh...@cup.hp.com>
> To: sebor@roguewave.com
> CC: Boris.Gubenko@hp.com, al.simons@hp.com, dhandly@cup.hp.com
> It appears this problem is still in the apache code:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
> It seems to violate 27.8.1.3(6), which says it always "finally" calls
> "as if" fclose(3). And returns an error if any calls fail.
> ================================================================
> >From: "Levie, Barry" <ba...@hp.com>
> Date: Thu, 7 Dec 2006 15:36:33 -0000
> Subject: aCC 3.70 -AA fd's close not being called.
> I am not sure if this exactly represents the problem the customer is
> having as I am still waiting for more details (versions/test case etc
> etc). However this could be close and I think it shows a problem.
> Why does the ofstream destructor not close the file descriptor when its
> called after its thrown an exception for "out of disk space".
> This aCC 3.70 -AA example shows an ever increasing number of open file
> descriptors in glance
> # what /usr/lib/libstd_v2.2:
> HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> #include <iostream>
> #include <fstream>
> #include <string.h>
> using namespace std;
> struct dummy {
> dummy() { cout << "\ndummy created \n" ;}
> ~dummy() { cout << "\ndummy deleted \n"; }
> };
> void bar() {
> char buf[1024*1024];
> memset(buf,'A',1024*1024);
> buf[1024*1024 -1] = 0;
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("/home/test.txt"); // this is on a volume that is nearly full.
> while(1) {
> of << buf;
> }
> }
> catch(ofstream::failure& e) {
> cout << "\nException write/file";
> }
> }
> int main () {
> while(1) bar();
> }
> # ./a.out
> dummy created
> msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
> (1 block extent)
> Exception write/file
> dummy deleted
> ....
> Glance output shows
> D File Name Type Mode Count Offset
> ---------------------------------------------------
> 0 /dev/pts/ta stream rd/wr 6 333822
> 1 /dev/pts/ta stream rd/wr 6 333822
> 2 /dev/pts/ta stream rd/wr 6 333822
> 3 /home/test.txt reg write 1 101957632
> 4 /home/test.txt reg write 1 101957632
> 5 /home/test.txt reg write 1 101957632
> ...
> ================================================================
> >From: Dennis Handly <dh...@cup.hp.com>
> Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
> To: acxx@cup.hp.com, barry.levie@hp.com
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> >From: "Levie, Barry" <ba...@hp.com>
> >I am not sure if this exactly represents the problem the customer is
> >having as I am still waiting for more details (versions/test case etc
> >etc). However this could be close and I think it shows a problem.
> >Why does the ofstream destructor not close the file descriptor when its
> >called after its thrown an exception for "out of disk space".
> A highly modified version works for me.
> And it isn't closed on the throw but by falling off the bar body.
> >This aCC 3.70 -AA example shows an ever increasing number of open file
> >descriptors in glance
> Hmm.
> ># what /usr/lib/libstd_v2.2:
> > HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> This obsolete version isn't supported.
> Here is what I have and it shows close being called after I throw.
> I've manually modified the write return to -1 and that throws and is caught.
> (The debugger was broken and it didn't really happen. )-:
> #include <iostream>
> #include <fstream>
> #include <string.h>
> #include <stdio.h>
> using namespace std;
> struct dummy {
> dummy() { fprintf(stdout, "dummy created\n"); fflush(stdout); }
> ~dummy() { fprintf(stdout, "dummy deleted\n"); fflush(stdout); }
> };
> extern "C" int _close(int fd);
> extern "C" int close(int fd) {
> if (fd > STDERR_FILENO) {
> fprintf(stdout, "close(%d)\n", fd);
> fflush(stdout);
> }
> return _close(fd);
> }
> char buf[1024];
> void bar() {
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("test.txt"); // this is on a volume that is nearly full.
> fprintf(stdout, "FD = %d\n", of.rdbuf()->fd());
> fflush(stdout);
> for (int i = 0; i < 2; ++i)
> of << buf;
> throw ios_base::failure();
> }
> catch(ofstream::failure &e) {
> fprintf(stdout, "Exception write/file\n");
> fflush(stdout);
> }
> }
> int main() {
> memset(buf,'A',sizeof(buf));
> buf[sizeof(buf)-1] = '\0';
> int i;
> for (i = 0; i < 10; ++i)
> bar();
> }
> Ah, it's catch 22. When it destroys ofstream it calls close, which calls
> overflow which calls _C_write which calls write which gets an error and
> then returns before closing.
> It seems it is working as designed be RW.
> But this seems to violate 27.8.1.3(6), which says it always calls
> fclose(3).
> File a CR.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (STDCXX-308) filebuf dtor doesn't close fd after
exception
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/STDCXX-308?page=comments#action_12457393 ]
Martin Sebor commented on STDCXX-308:
-------------------------------------
-------- Original Message --------
Subject: Re: aCC 3.70 -AA fd's close not being called.
Date: Fri, 08 Dec 2006 11:47:51 -0700
From: Martin Sebor <se...@roguewave.com>
Organization: Rogue Wave Software
To: Dennis Handly <dh...@cup.hp.com>
CC: Boris.Gubenko@hp.com, al.simons@hp.com
References: <20...@hpcll183.hp.com>
Dennis Handly wrote:
> It appears this problem is still in the apache code:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
>
> It seems to violate 27.8.1.3(6), which says it always "finally" calls
> "as if" fclose(3). And returns an error if any calls fail.
I agree that it's a bug that the dtor leaks the fd when
close() fails. The question is whose fault is it, ours
or the standard's? ;-)
I don't think the text is clear about close() being
required to call fclose() even if overflow() fails
(or throws). Further, suppose close() is being called
directly (as opposed from the dtor). Should it close
the fd even if overflow() failed due to some transient
and recoverable error? Since close() indicates success
or error to the caller I think it should only call
fclose() if overflow() returns successfully. Otherwise
it should leave it open so that the caller can fix the
problem and not lose data.
OTOH, the dtor should never leak the fd and should be
required to close it regardless of whether overflow is
or isn't successful, and it should probably not
propagate exceptions. But to do that the spec needs to
specify this behavior explicitly. Let me raise it on
the reflector.
Martin
> filebuf dtor doesn't close fd after exception
> ---------------------------------------------
>
> Key: STDCXX-308
> URL: http://issues.apache.org/jira/browse/STDCXX-308
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
> Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Assigned To: Martin Sebor
>
> -------- Original Message --------
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
> From: Dennis Handly <dh...@cup.hp.com>
> To: sebor@roguewave.com
> CC: Boris.Gubenko@hp.com, al.simons@hp.com, dhandly@cup.hp.com
> It appears this problem is still in the apache code:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
> It seems to violate 27.8.1.3(6), which says it always "finally" calls
> "as if" fclose(3). And returns an error if any calls fail.
> ================================================================
> >From: "Levie, Barry" <ba...@hp.com>
> Date: Thu, 7 Dec 2006 15:36:33 -0000
> Subject: aCC 3.70 -AA fd's close not being called.
> I am not sure if this exactly represents the problem the customer is
> having as I am still waiting for more details (versions/test case etc
> etc). However this could be close and I think it shows a problem.
> Why does the ofstream destructor not close the file descriptor when its
> called after its thrown an exception for "out of disk space".
> This aCC 3.70 -AA example shows an ever increasing number of open file
> descriptors in glance
> # what /usr/lib/libstd_v2.2:
> HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> #include <iostream>
> #include <fstream>
> #include <string.h>
> using namespace std;
> struct dummy {
> dummy() { cout << "\ndummy created \n" ;}
> ~dummy() { cout << "\ndummy deleted \n"; }
> };
> void bar() {
> char buf[1024*1024];
> memset(buf,'A',1024*1024);
> buf[1024*1024 -1] = 0;
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("/home/test.txt"); // this is on a volume that is nearly full.
> while(1) {
> of << buf;
> }
> }
> catch(ofstream::failure& e) {
> cout << "\nException write/file";
> }
> }
> int main () {
> while(1) bar();
> }
> # ./a.out
> dummy created
> msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
> (1 block extent)
> Exception write/file
> dummy deleted
> ....
> Glance output shows
> D File Name Type Mode Count Offset
> ---------------------------------------------------
> 0 /dev/pts/ta stream rd/wr 6 333822
> 1 /dev/pts/ta stream rd/wr 6 333822
> 2 /dev/pts/ta stream rd/wr 6 333822
> 3 /home/test.txt reg write 1 101957632
> 4 /home/test.txt reg write 1 101957632
> 5 /home/test.txt reg write 1 101957632
> ...
> ================================================================
> >From: Dennis Handly <dh...@cup.hp.com>
> Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
> To: acxx@cup.hp.com, barry.levie@hp.com
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> >From: "Levie, Barry" <ba...@hp.com>
> >I am not sure if this exactly represents the problem the customer is
> >having as I am still waiting for more details (versions/test case etc
> >etc). However this could be close and I think it shows a problem.
> >Why does the ofstream destructor not close the file descriptor when its
> >called after its thrown an exception for "out of disk space".
> A highly modified version works for me.
> And it isn't closed on the throw but by falling off the bar body.
> >This aCC 3.70 -AA example shows an ever increasing number of open file
> >descriptors in glance
> Hmm.
> ># what /usr/lib/libstd_v2.2:
> > HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> This obsolete version isn't supported.
> Here is what I have and it shows close being called after I throw.
> I've manually modified the write return to -1 and that throws and is caught.
> (The debugger was broken and it didn't really happen. )-:
> #include <iostream>
> #include <fstream>
> #include <string.h>
> #include <stdio.h>
> using namespace std;
> struct dummy {
> dummy() { fprintf(stdout, "dummy created\n"); fflush(stdout); }
> ~dummy() { fprintf(stdout, "dummy deleted\n"); fflush(stdout); }
> };
> extern "C" int _close(int fd);
> extern "C" int close(int fd) {
> if (fd > STDERR_FILENO) {
> fprintf(stdout, "close(%d)\n", fd);
> fflush(stdout);
> }
> return _close(fd);
> }
> char buf[1024];
> void bar() {
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("test.txt"); // this is on a volume that is nearly full.
> fprintf(stdout, "FD = %d\n", of.rdbuf()->fd());
> fflush(stdout);
> for (int i = 0; i < 2; ++i)
> of << buf;
> throw ios_base::failure();
> }
> catch(ofstream::failure &e) {
> fprintf(stdout, "Exception write/file\n");
> fflush(stdout);
> }
> }
> int main() {
> memset(buf,'A',sizeof(buf));
> buf[sizeof(buf)-1] = '\0';
> int i;
> for (i = 0; i < 10; ++i)
> bar();
> }
> Ah, it's catch 22. When it destroys ofstream it calls close, which calls
> overflow which calls _C_write which calls write which gets an error and
> then returns before closing.
> It seems it is working as designed be RW.
> But this seems to violate 27.8.1.3(6), which says it always calls
> fclose(3).
> File a CR.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (STDCXX-308) filebuf dtor doesn't close fd after
exception
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522292 ]
Martin Sebor commented on STDCXX-308:
-------------------------------------
Filed issue 622:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622
> filebuf dtor doesn't close fd after exception
> ---------------------------------------------
>
> Key: STDCXX-308
> URL: https://issues.apache.org/jira/browse/STDCXX-308
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
> Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Assignee: Martin Sebor
>
> -------- Original Message --------
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
> From: Dennis Handly <dh...@cup.hp.com>
> To: sebor@roguewave.com
> CC: Boris.Gubenko@hp.com, al.simons@hp.com, dhandly@cup.hp.com
> It appears this problem is still in the apache code:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
> It seems to violate 27.8.1.3(6), which says it always "finally" calls
> "as if" fclose(3). And returns an error if any calls fail.
> ================================================================
> >From: "Levie, Barry" <ba...@hp.com>
> Date: Thu, 7 Dec 2006 15:36:33 -0000
> Subject: aCC 3.70 -AA fd's close not being called.
> I am not sure if this exactly represents the problem the customer is
> having as I am still waiting for more details (versions/test case etc
> etc). However this could be close and I think it shows a problem.
> Why does the ofstream destructor not close the file descriptor when its
> called after its thrown an exception for "out of disk space".
> This aCC 3.70 -AA example shows an ever increasing number of open file
> descriptors in glance
> # what /usr/lib/libstd_v2.2:
> HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> #include <iostream>
> #include <fstream>
> #include <string.h>
> using namespace std;
> struct dummy {
> dummy() { cout << "\ndummy created \n" ;}
> ~dummy() { cout << "\ndummy deleted \n"; }
> };
> void bar() {
> char buf[1024*1024];
> memset(buf,'A',1024*1024);
> buf[1024*1024 -1] = 0;
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("/home/test.txt"); // this is on a volume that is nearly full.
> while(1) {
> of << buf;
> }
> }
> catch(ofstream::failure& e) {
> cout << "\nException write/file";
> }
> }
> int main () {
> while(1) bar();
> }
> # ./a.out
> dummy created
> msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
> (1 block extent)
> Exception write/file
> dummy deleted
> ....
> Glance output shows
> D File Name Type Mode Count Offset
> ---------------------------------------------------
> 0 /dev/pts/ta stream rd/wr 6 333822
> 1 /dev/pts/ta stream rd/wr 6 333822
> 2 /dev/pts/ta stream rd/wr 6 333822
> 3 /home/test.txt reg write 1 101957632
> 4 /home/test.txt reg write 1 101957632
> 5 /home/test.txt reg write 1 101957632
> ...
> ================================================================
> >From: Dennis Handly <dh...@cup.hp.com>
> Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
> To: acxx@cup.hp.com, barry.levie@hp.com
> Subject: Re: aCC 3.70 -AA fd's close not being called.
> >From: "Levie, Barry" <ba...@hp.com>
> >I am not sure if this exactly represents the problem the customer is
> >having as I am still waiting for more details (versions/test case etc
> >etc). However this could be close and I think it shows a problem.
> >Why does the ofstream destructor not close the file descriptor when its
> >called after its thrown an exception for "out of disk space".
> A highly modified version works for me.
> And it isn't closed on the throw but by falling off the bar body.
> >This aCC 3.70 -AA example shows an ever increasing number of open file
> >descriptors in glance
> Hmm.
> ># what /usr/lib/libstd_v2.2:
> > HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
> This obsolete version isn't supported.
> Here is what I have and it shows close being called after I throw.
> I've manually modified the write return to -1 and that throws and is caught.
> (The debugger was broken and it didn't really happen. )-:
> #include <iostream>
> #include <fstream>
> #include <string.h>
> #include <stdio.h>
> using namespace std;
> struct dummy {
> dummy() { fprintf(stdout, "dummy created\n"); fflush(stdout); }
> ~dummy() { fprintf(stdout, "dummy deleted\n"); fflush(stdout); }
> };
> extern "C" int _close(int fd);
> extern "C" int close(int fd) {
> if (fd > STDERR_FILENO) {
> fprintf(stdout, "close(%d)\n", fd);
> fflush(stdout);
> }
> return _close(fd);
> }
> char buf[1024];
> void bar() {
> ofstream of;
> dummy df;
> of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
> try {
> of.open("test.txt"); // this is on a volume that is nearly full.
> fprintf(stdout, "FD = %d\n", of.rdbuf()->fd());
> fflush(stdout);
> for (int i = 0; i < 2; ++i)
> of << buf;
> throw ios_base::failure();
> }
> catch(ofstream::failure &e) {
> fprintf(stdout, "Exception write/file\n");
> fflush(stdout);
> }
> }
> int main() {
> memset(buf,'A',sizeof(buf));
> buf[sizeof(buf)-1] = '\0';
> int i;
> for (i = 0; i < 10; ++i)
> bar();
> }
> Ah, it's catch 22. When it destroys ofstream it calls close, which calls
> overflow which calls _C_write which calls write which gets an error and
> then returns before closing.
> It seems it is working as designed be RW.
> But this seems to violate 27.8.1.3(6), which says it always calls
> fclose(3).
> File a CR.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.