[IOStreams] Opinion on test case needed
Hi! I had problems using iostreams::stream<file_descriptor> with Windows and MSVC 8 Express. The file_descriptor had a bug and failed seeking. But the error had gone unnoticed. Because of this I wrote a test case for this in hope to discover an error in IOStreams (source: see below). I did not discover one. Instead the test runs fine on linux/gcc 4.1.2 but fails on Windows/MSVC8Express (test run: see below). I based the test on "Standard C++ IOStreams and Locales" (Langer&Kreft), Section 1.3 "The Stream State". And I found the IOStreams library is just using std::iostream for handling the errors. So is MSVC buggy in this regard? Or am I missing something? Source of test case in Trac SVN Browser: http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iostr... Result of test case on platform Windows/MSVC 8 Express:
...using <p..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug>error_test.exe... testing.capture-output ..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug\error_test.run ====== BEGIN OUTPUT ====== Running 12 test cases... error_test.cpp(81): error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) error_test.cpp(66): error in "wrap_nothrow <&test_seekg>": stream still good error_test.cpp(68): error in "wrap_nothrow <&test_seekg>": stream did not set badbit error_test.cpp(69): error in "wrap_nothrow <&test_seekg>": stream did not fail error_test.cpp(71): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator void* error_test.cpp(66): error in "wrap_throw <&test_seekg>": stream still good error_test.cpp(68): error in "wrap_throw <&test_seekg>": stream did not set badbit error_test.cpp(69): error in "wrap_throw <&test_seekg>": stream did not fail error_test.cpp(71): error in "wrap_throw <&test_seekg>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_throw <&test_seekg>": stream does not report failure by operator void* unknown location(0): fatal error in "wrap_throw_delayed<&test_seekg>": std::runtime_error: bad seek error_test.cpp(73): last checkpoint error_test.cpp(81): error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) error_test.cpp(66): error in "wrap_nothrow <&test_seekp>": stream still good error_test.cpp(68): error in "wrap_nothrow <&test_seekp>": stream did not set badbit error_test.cpp(69): error in "wrap_nothrow <&test_seekp>": stream did not fail error_test.cpp(71): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator void* error_test.cpp(66): error in "wrap_throw <&test_seekp>": stream still good error_test.cpp(68): error in "wrap_throw <&test_seekp>": stream did not set badbit error_test.cpp(69): error in "wrap_throw <&test_seekp>": stream did not fail error_test.cpp(71): error in "wrap_throw <&test_seekp>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_throw <&test_seekp>": stream does not report failure by operator void* unknown location(0): fatal error in "wrap_throw_delayed<&test_seekp>": std::runtime_error: bad seek error_test.cpp(73): last checkpoint
*** 24 failures detected in test suite "Master Test Suite"
EXIT STATUS: 201 ====== END OUTPUT ======
Any opinions on this? Any suggestions on what to do about it? Frank
Frank Birbacher wrote:
Hi!
Frank Birbacher schrieb:
Any opinions on this? Any suggestions on what to do about it?
Anyone to test this on another platform?
hmmm... I tried to checkout the test dir as follows: svn checkout http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iostr... and I get the following errors: svn: PROPFIND request failed on '/trac/boost/browser/sandbox-branches/birbacher/fix_iostreams/libs/iostreams/test' svn: PROPFIND of '/trac/boost/browser/sandbox-branches/birbacher/fix_iostreams/libs/iostreams/test': 200 OK (http://svn.boost.org)
Hi! eg schrieb:
hmmm... I tried to checkout the test dir as follows:
svn checkout http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iostr...
and I get the following errors:
Yes, in the beginning I did that, too. It is because the Trac browser does not support the checkout. For an actual svn checkout one needs to supply the svn path: http://svn.boost.org/svn/boost/sandbox-branches/birbacher/fix_iostreams/libs... (note: no "trac" in the URL) I'm glad to hear somebody who's willing to test this! :D Frank
Frank Birbacher wrote:
http://svn.boost.org/svn/boost/sandbox-branches/birbacher/fix_iostreams/libs...
(note: no "trac" in the URL)
I'm glad to hear somebody who's willing to test this! :D
Thanks for the info. I was able to compile/run all the tests except the error_test.cpp you added on Windows using Visual Studio .Net 2003 (professional). Unfortunately, it generates an internal compiler error: ----------------- compile-c-c++ ..\..\..\bin.v2\libs\iostreams\fix-iostreams\error_test.test\msvc- 7.1\debug\threading-multi\error_test.obj error_test.cpp c:\dev\boost_1_34_1\libs\iostreams\fix-iostreams\error_test.cpp(142) : fatal err or C1001: INTERNAL COMPILER ERROR (compiler file 'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c ', line 148) ---------------- This appears to have hit a bug in the VS.Net 2003 compiler which wasn't fixed until VS 2005 SP1. For details see: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac...
Hi! eg schrieb:
Unfortunately, it generates an internal compiler error:
Oops.
This appears to have hit a bug in the VS.Net 2003 compiler which wasn't fixed until VS 2005 SP1. For details see: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac...
Great, thanks for the link. Seems to be a strange bug. The description says reduce the optimization level as a workaround. But you already used debug mode. Just a wild guess: does it work with variant=release optimization=space ? If that doesn't work maybe I should get hold on a previous Visual Studio myself to investigate this further. And even if I overcome the ICE there is still the wrong behaviour which the test should (actually it should not ;) ) reveal. Thanks, Frank
Frank Birbacher wrote:
Just a wild guess: does it work with variant=release optimization=space ?
Unfortunately not. compile-c-c++ ..\..\..\bin.v2\libs\iostreams\fix-iostreams\error_test.test\msvc- 7.1\release\optimization-space\threading-multi\error_test.obj error_test.cpp c:\dev\boost_1_34_1\libs\iostreams\fix-iostreams\error_test.cpp(142) : fatal err or C1001: INTERNAL COMPILER ERROR (compiler file 'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c ', line 148) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
If that doesn't work maybe I should get hold on a previous Visual Studio myself to investigate this further. And even if I overcome the ICE there is still the wrong behaviour which the test should (actually it should not ;) ) reveal.
I can try it on Visual Studio 2005 Professional next week. Just in case there is a difference between this and the Express one which you used.
Hi! eg schrieb:
Frank Birbacher wrote:
Just a wild guess: does it work with variant=release optimization=space ?
Unfortunately not.
:(
I can try it on Visual Studio 2005 Professional next week. Just in case there is a difference between this and the Express one which you used.
Sure, great! But I'm not confident of Pro and Express being different. Frank
I can try it on Visual Studio 2005 Professional next week. Just in case there is a difference between this and the Express one which you used.
Sure, great! But I'm not confident of Pro and Express being different.
For completeness, you were right of course... they are the same. I see from your other thread that you have made progress on this.
Hi! Frank Birbacher schrieb:
I based the test on "Standard C++ IOStreams and Locales" (Langer&Kreft), Section 1.3 "The Stream State". And I found the IOStreams library is just using std::iostream for handling the errors. So is MSVC buggy in this regard? Or am I missing something?
Source of test case in Trac SVN Browser: http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iostr...
I just tried to run the same test with STLport 5.1.3 and MSVC8Express, and unfortenuately I get the same errors and a couple of memory leaks. What's wrong here??? Running 12 test cases... error_test.cpp(81): error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) error_test.cpp(66): error in "wrap_nothrow <&test_seekg>": stream still good error_test.cpp(68): error in "wrap_nothrow <&test_seekg>": stream did not set badbit error_test.cpp(69): error in "wrap_nothrow <&test_seekg>": stream did not fail error_test.cpp(71): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator void* error_test.cpp(66): error in "wrap_throw <&test_seekg>": stream still good error_test.cpp(68): error in "wrap_throw <&test_seekg>": stream did not set badbit error_test.cpp(69): error in "wrap_throw <&test_seekg>": stream did not fail error_test.cpp(71): error in "wrap_throw <&test_seekg>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_throw <&test_seekg>": stream does not report failure by operator void* error_test.cpp(103): error in "wrap_throw_delayed<&test_seekg>": exception thrown by function(stream) error_test.cpp(107): error in "wrap_throw_delayed<&test_seekg>": exception ios::failure is expected error_test.cpp(66): error in "wrap_throw_delayed<&test_seekg>": stream still good error_test.cpp(68): error in "wrap_throw_delayed<&test_seekg>": stream did not set badbit error_test.cpp(69): error in "wrap_throw_delayed<&test_seekg>": stream did not fail error_test.cpp(71): error in "wrap_throw_delayed<&test_seekg>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_throw_delayed<&test_seekg>": stream does not report failure by operator void* error_test.cpp(81): error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) error_test.cpp(66): error in "wrap_nothrow <&test_seekp>": stream still good error_test.cpp(68): error in "wrap_nothrow <&test_seekp>": stream did not set badbit error_test.cpp(69): error in "wrap_nothrow <&test_seekp>": stream did not fail error_test.cpp(71): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator void* error_test.cpp(66): error in "wrap_throw <&test_seekp>": stream still good error_test.cpp(68): error in "wrap_throw <&test_seekp>": stream did not set badbit error_test.cpp(69): error in "wrap_throw <&test_seekp>": stream did not fail error_test.cpp(71): error in "wrap_throw <&test_seekp>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_throw <&test_seekp>": stream does not report failure by operator void* error_test.cpp(103): error in "wrap_throw_delayed<&test_seekp>": exception thrown by function(stream) error_test.cpp(107): error in "wrap_throw_delayed<&test_seekp>": exception ios::failure is expected error_test.cpp(66): error in "wrap_throw_delayed<&test_seekp>": stream still good error_test.cpp(68): error in "wrap_throw_delayed<&test_seekp>": stream did not set badbit error_test.cpp(69): error in "wrap_throw_delayed<&test_seekp>": stream did not fail error_test.cpp(71): error in "wrap_throw_delayed<&test_seekp>": stream does not report failure by operator ! error_test.cpp(73): error in "wrap_throw_delayed<&test_seekp>": stream does not report failure by operator void* *** 36 failures detected in test suite "Master Test Suite" Detected memory leaks! Dumping objects -> {212} normal block at 0x0036ABF0, 2816 bytes long. Data: < 6 6 > 18 B0 36 00 18 B0 36 00 00 00 00 00 00 00 00 00 {159} normal block at 0x00367C18, 4152 bytes long. Data: <8 6 B B > 38 83 36 00 93 C3 42 00 00 00 00 00 88 C3 42 00 {158} normal block at 0x00367868, 896 bytes long. Data: < y6 B $ B / B > 88 79 36 00 F4 C0 42 00 24 C3 42 00 2F C3 42 00 {152} normal block at 0x00367148, 848 bytes long. Data: < n6 > 08 6E 36 00 CD CD CD CD CD CD CD CD CD CD CD CD {144} normal block at 0x00366B78, 792 bytes long. Data: < l6 > A8 6C 36 00 CD CD CD CD CD CD CD CD CD CD CD CD {142} normal block at 0x00366608, 752 bytes long. Data: <8g6 > 38 67 36 00 CD CD CD CD CD CD CD CD CD CD CD CD {128} normal block at 0x00365DF8, 704 bytes long. Data: <(_6 > 28 5F 36 00 CD CD CD CD CD CD CD CD CD CD CD CD {126} normal block at 0x003658E0, 664 bytes long. Data: < Z6 day > 10 5A 36 00 64 61 79 00 CD CD CD CD CD CD CD CD {111} normal block at 0x00365180, 320 bytes long. Data: < R6 > 18 52 36 00 CD CD CD CD 00 00 00 00 CD CD CD CD Object dump complete. EXIT STATUS: 201 What's wrong here??? Frank
on Tue Sep 04 2007, Frank Birbacher <bloodymir.crap-AT-gmx.net> wrote:
Frank Birbacher schrieb:
I based the test on "Standard C++ IOStreams and Locales" (Langer&Kreft), Section 1.3 "The Stream State". And I found the IOStreams library is just using std::iostream for handling the errors. So is MSVC buggy in this regard? Or am I missing something?
Source of test case in Trac SVN Browser: http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iostr...
I just tried to run the same test with STLport 5.1.3 and MSVC8Express, and unfortenuately I get the same errors and a couple of memory leaks.
What's wrong here???
Running 12 test cases... error_test.cpp(81): error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) error_test.cpp(66): error in "wrap_nothrow <&test_seekg>": stream still good error_test.cpp(68): error in "wrap_nothrow <&test_seekg>": stream did not set badbit error_test.cpp(69): error in "wrap_nothrow <&test_seekg>": stream did not fail
I would guess from looking at these messages that somebody has set the bit on the stream that causes it to throw on error, but that the test case is expecting errors to be reported by setting badbit. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Hi! David Abrahams schrieb:
I would guess from looking at these messages that somebody has set the bit on the stream that causes it to throw on error, but that the test case is expecting errors to be reported by setting badbit.
If a stream operation throws this has also the effect of setting the fail of badbit depending on the exception origin. And my origin is excepted to set the badbit regadless of the exception mask. The most anoying point is the following case: 1. construct stream with custom streambuf 2. _NO_ exceptions enabled 3. provoke exception result: Nothing. Neither is the exception propagated nor is the fail or badbit set. That is a serious bug IMHO. Frank
on Tue Sep 04 2007, Frank Birbacher <bloodymir.crap-AT-gmx.net> wrote:
The most anoying point is the following case: 1. construct stream with custom streambuf 2. _NO_ exceptions enabled 3. provoke exception result: Nothing. Neither is the exception propagated nor is the fail or badbit set. That is a serious bug IMHO.
In what code? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Hi! David Abrahams schrieb:
on Tue Sep 04 2007, Frank Birbacher <bloodymir.crap-AT-gmx.net> wrote:
The most anoying point is the following case: 1. construct stream with custom streambuf 2. _NO_ exceptions enabled 3. provoke exception result: Nothing. Neither is the exception propagated nor is the fail or badbit set. That is a serious bug IMHO.
In what code?
Hmm, the original file_descriptor code raised an exception in its write function. The error didn't show up because of the behaviour described above. This was the hard to find bug in my program. In an attempt to show the error I wrote some test cases. This test suite spit a couple of errors out and I didn't realize the original problem/bug didn't actually show there. I jsut reproduced the original error and I'll try to figure out how to express this in a test case. Anyway the other failing test cases are also pointing out some misbehaviour of the standard library, I think. Definately something to look at. Frank
Hi! David Abrahams schrieb:
In what code?
I got a test case which shows the error. http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/tmp_iostr... (notice: new branch) The new test case does (test_write_close): 1. crete a stream in "open" state 2. try writing to it (streambuf does not yet throw) 3. close the stream !!! (stream buffer should be flushed and streambuf should throw now and cause badbit to be set) 4. test for errors: NONE?! Results of the test suite:
====== BEGIN OUTPUT ====== Running 15 test cases... error_test.cpp(75): fatal error in "wrap_nothrow <&test_write_close>": stream still good error_test.cpp(101): fatal error in "wrap_throw <&test_write_close>": exception std::exception is expected error_test.cpp(116): fatal error in "wrap_throw_delayed<&test_write_close>": exception ios::failure is expected error_test.cpp(90): fatal error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) error_test.cpp(75): fatal error in "wrap_throw <&test_seekg>": stream still good error_test.cpp(112): fatal error in "wrap_throw_delayed<&test_seekg>": exception thrown by function(stream) error_test.cpp(90): fatal error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) error_test.cpp(75): fatal error in "wrap_throw <&test_seekp>": stream still good error_test.cpp(112): fatal error in "wrap_throw_delayed<&test_seekp>": exception thrown by function(stream)
*** 9 failures detected in test suite "Master Test Suite"
EXIT STATUS: 201 ====== END OUTPUT ======
This is clearly not the behaviour which I'd expect. Frank
Hi! David Abrahams schrieb:
In what code?
I got a test case which shows the error. http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/tmp_iostr... (notice: new branch) The new test case does (test_write_close): 1. crete a stream in "open" state 2. try writing to it (streambuf does not yet throw) 3. close the stream !!! (stream buffer should be flushed and streambuf should throw now and cause badbit to be set) 4. test for errors: NONE?! Results of the test suite:
====== BEGIN OUTPUT ====== Running 15 test cases... error_test.cpp(75): fatal error in "wrap_nothrow <&test_write_close>": stream still good error_test.cpp(101): fatal error in "wrap_throw <&test_write_close>": exception std::exception is expected error_test.cpp(116): fatal error in "wrap_throw_delayed<&test_write_close>": exception ios::failure is expected error_test.cpp(90): fatal error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) error_test.cpp(75): fatal error in "wrap_throw <&test_seekg>": stream still good error_test.cpp(112): fatal error in "wrap_throw_delayed<&test_seekg>": exception thrown by function(stream) error_test.cpp(90): fatal error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) error_test.cpp(75): fatal error in "wrap_throw <&test_seekp>": stream still good error_test.cpp(112): fatal error in "wrap_throw_delayed<&test_seekp>": exception thrown by function(stream)
*** 9 failures detected in test suite "Master Test Suite"
EXIT STATUS: 201 ====== END OUTPUT ======
This is clearly not the behaviour which I'd expect. Frank
Frank Birbacher wrote: Thanks for bringing up this issue (and for all your other work). I have renamed the test stream_state_test.cpp (since all of the tests check for errors in one way or another). It's clear that this test fails on a variety of standard libraries, so I have commented it out until I determine whether 1. The standard requires that it pass 2. If so, whether there is anything Boost.Iostreams can do about it 3. If not, whether it can be modified so that a. the standard requires it to pass b. it fails with some standard libraries, and c. Boost.Iostreams can provide workarounds Let me know if you have reached any conclusions since you posted your original messages. -- Jonathan Turkanis CodeRage http://www.coderage.com
participants (4)
-
David Abrahams -
eg -
Frank Birbacher -
Jonathan Turkanis