[test] Shouldn't a run-fail test pass on abort()?
It seems that a run-fail test does not pass when test_main() calls abort() or assert( false ). Is there any way how I can test these scenarios? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
David Abrahams wrote:
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
It seems that a run-fail test does not pass when test_main() calls abort() or assert( false ).
It should! What result are you seeing?
See output.txt, Jamfile and source are also attached. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Update: No matter how the test fails (abort(), assert( false ), throw std::logic_error( "" );, return -1;), it is always shown as a failure and not as a pass! I guess I'm missing something substantial here. BTW, I'm using 1.32 Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message news:d8ehdf$14o$1@sea.gmane.org...
Update: No matter how the test fails (abort(), assert( false ), throw std::logic_error( "" );, return -1;), it is always shown as a failure and not as a pass! I guess I'm missing something substantial here. BTW, I'm using 1.32
Regards,
From what I see on rergression pages - I think it's fixes. It used to be all run-fail tests in Boost.Test were failing on Linux.
Gennadiy
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
Update: No matter how the test fails (abort(), assert( false ), throw std::logic_error( "" );, return -1;), it is always shown as a failure and not as a pass! I guess I'm missing something substantial here. BTW, I'm using 1.32
The tests are passing. The only build rules that are failing are the ones designed to remove temporary files, which I guess should be made more resilient, and I'm guessing are the reason you're not seeing ** passed ** in your output. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
Update: No matter how the test fails (abort(), assert( false ), throw std::logic_error( "" );, return -1;), it is always shown as a failure and not as a pass! I guess I'm missing something substantial here. BTW, I'm using 1.32
The tests are passing. The only build rules that are failing are the ones designed to remove temporary files, which I guess should be made more resilient, and I'm guessing are the reason you're not seeing ** passed ** in your output.
You're probably right. It looks like there's something wrong on my machine. Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
David Abrahams wrote:
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
It seems that a run-fail test does not pass when test_main() calls abort() or assert( false ). It should! What result are you seeing?
See output.txt, Jamfile and source are also attached.
Something is strange about this. Can you do the exact same thing again, but with bjam -d+2, and post the output? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Something is strange about this. Can you do the exact same thing again, but with bjam -d+2, and post the output?
Sure. Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
David Abrahams wrote:
Something is strange about this. Can you do the exact same thing again, but with bjam -d+2, and post the output?
Sure.
Okay, I'm officially confused. This segment from your original output indicates that the build system is trying (and failing) to delete the RunFailTest executable: ---- del /f/q "..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailTest.exe" ...failed RmTemps ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailTest.run... ---- The only reason that should fail is if the executable is missing. Now if I look at the new output, I can trace the steps from creation of that executable up until we try to execute the del command. It clearly gets created and executed, and there's no attempt to delete it before this one. So if you do bjam -a -otest.bat -sTOOLS=mingw RunFailTest.run can you then execute all the commands in test.bat? Does the "del" command work? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Okay, I'm officially confused. This segment from your original output indicates that the build system is trying (and failing) to delete the RunFailTest executable:
---- del /f/q "..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailTest.exe"
...failed RmTemps ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailTest.run... ----
The only reason that should fail is if the executable is missing. Now if I look at the new output, I can trace the steps from creation of that executable up until we try to execute the del command. It clearly gets created and executed, and there's no attempt to delete it before this one.
Very strange indeed. At first I suspected that the virus scanner is interfering but the results are exactly the same if it is disabled. The executable does disappear after execution, BTW.
So if you do
bjam -a -otest.bat -sTOOLS=mingw RunFailTest.run
can you then execute all the commands in test.bat? Does the "del" command work?
I assume you mean bjam -a -otest.bat -sTOOLS=mingw RunFailTest (note the missing .run) When I do that the del command does not end up in the test.bat file, see attached. I used the following command line to make test.bat: bjam "-sTOOLS=mingw" "-sMINGW_ROOT_DIRECTORY=C:\ProgramFiles\MinGW3.2.0" -a -otest.bat RunFailTest I'll try the same stuff tomorrow on my laptop... Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
David Abrahams wrote:
Okay, I'm officially confused. This segment from your original output indicates that the build system is trying (and failing) to delete the RunFailTest executable:
---- del /f/q "..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailTest.exe"
...failed RmTemps ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailTest.run... ----
The only reason that should fail is if the executable is missing. Now if I look at the new output, I can trace the steps from creation of that executable up until we try to execute the del command. It clearly gets created and executed, and there's no attempt to delete it before this one.
Very strange indeed. At first I suspected that the virus scanner is interfering but the results are exactly the same if it is disabled. The executable does disappear after execution, BTW.
So if you do
bjam -a -otest.bat -sTOOLS=mingw RunFailTest.run
can you then execute all the commands in test.bat? Does the "del" command work?
I assume you mean
bjam -a -otest.bat -sTOOLS=mingw RunFailTest
(note the missing .run)
I meant what I wrote. Does it fail to work? If so, just use the target called "test" -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes:
So if you do
bjam -a -otest.bat -sTOOLS=mingw RunFailTest.run
can you then execute all the commands in test.bat? Does the "del" command work?
I assume you mean
bjam -a -otest.bat -sTOOLS=mingw RunFailTest
(note the missing .run)
I meant what I wrote. Does it fail to work?
Yes, the output is <output> don't know how to make RunFailTest.run ...found 1 target... ...can't find 1 target... </output>
If so, just use the target called "test"
Ok, that works but there's still no del command in test.bat. I can't add attachments in the online news reader, so I copy-pasted the relevant part at the end of this message. I conducted this test and the one without the -o switch on my recently reinstalled Laptop, but the results are exactly the same as on my computer at home. I also tested with the prebuilt bjam executable available on SourceForge as well as a newly built one from the current CVS, still no change. BTW, the whole problem arised because I wanted to test that some code asserts under certain circumstances. As a workaround I now have BOOST_ASSERT throw an exception and test for that with a normal run rule. Not optimal but ok for testing purposes. Therefore, if you don't want to invest more time in this that's ok with me. Thanks very much, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header. <TestBatExcerpt> "C:\ProgramFiles\MinGW\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 - fno-inline -mno-cygwin -I"..\..\..\bin\boost\libs\statechart\test" - I "D:\Andreas\My Documents\Statechart\boost_1_32_0" - o "..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFail Test.obj" "..\..\..\libs\statechart\test\RunFailTest.cpp" "C:\ProgramFiles\MinGW\bin\g++" "-Wl,--enable-auto-image-base" -g -Wl,- -allow-multiple-definition -mno-cygwin - o "..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFail Test.exe" - L"../../../bin/boost/libs/test/build/libboost_test_exec_monitor.lib/mingw/debug " - L"C:/ProgramFiles/MinGW/lib" "..\..\..\bin\boost\libs\statechart\test\RunFailT est.test\mingw\debug\RunFailTest.obj" "..\..\..\bin\boost\libs\test\build\libb oost_test_exec_monitor.lib\mingw\debug\libboost_test_exec_monitor.lib" "..\..\ ..\bin\boost\libs\test\build\libboost_test_exec_monitor.lib\mingw\debug\libboos t_test_exec_monitor.lib" set PATH=C:/ProgramFiles/MinGW/lib;%PATH% ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFai lTest.exe
..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFailT est.output 2>&1 set status=%ERRORLEVEL% echo.
..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFail Test.output echo EXIT STATUS: %status% ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunFail Test.output if %status% EQU 0 (
copy ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunF ailTest.output ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\ debug\RunFailTest.run ) set verbose=1 if %status% NEQ 0 ( set verbose=0 ) if %verbose% EQU 0 ( echo ====== BEGIN OUTPUT ====== type ..\..\..\bin\boost\libs\statechart\test\RunFailTest.test\mingw\debug\RunF ailTest.output echo ====== END OUTPUT ====== ) exit %status% </TestBatExcerpt>
At 10:22 2005-06-10, Andreas Huber wrote:
It seems that a run-fail test does not pass when test_main() calls abort() or assert( false ). Is there any way how I can test these scenarios?
perhaps we need to define our (boost) own abort and assert so that we _can_ capture the errors
Thanks & Regards,
-- Andreas Huber
When replying by private email, please remove the words spam and trap from the address shown in the header.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> wrote in message news:6.2.1.2.2.20050610111145.0405ad70@mail.rudbek.com...
At 10:22 2005-06-10, Andreas Huber wrote:
It seems that a run-fail test does not pass when test_main() calls abort() or assert( false ). Is there any way how I can test these scenarios?
perhaps we need to define our (boost) own abort and assert so that we _can_ capture the errors
See recent thread on Boost.Users: http://lists.boost.org/boost-users/2005/06/12086.php Gennadiy
Gennadiy Rozental wrote:
"Victor A. Wagner Jr." <vawjr@rudbek.com> wrote in message news:6.2.1.2.2.20050610111145.0405ad70@mail.rudbek.com...
At 10:22 2005-06-10, Andreas Huber wrote:
It seems that a run-fail test does not pass when test_main() calls abort() or assert( false ). Is there any way how I can test these scenarios?
perhaps we need to define our (boost) own abort and assert so that we _can_ capture the errors
See recent thread on Boost.Users:
Hmmm, wouldn't it be a good idea if the test monitor defined BOOST_ENABLE_ASSERT_HANDLER and a boost::assertion_failed function in DEBUG builds? Something similar could be done to detect calls to terminate(). Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
See recent thread on Boost.Users:
Hmmm, wouldn't it be a good idea if the test monitor defined BOOST_ENABLE_ASSERT_HANDLER and a boost::assertion_failed function in DEBUG builds?
Sorry I do not follow. Do you propose any changes to Boost.Test or Boost.Build?
Something similar could be done to detect calls to terminate().
Like for example?
Regards,
Gennadiy
Gennadiy Rozental wrote:
Hmmm, wouldn't it be a good idea if the test monitor defined BOOST_ENABLE_ASSERT_HANDLER and a boost::assertion_failed function in DEBUG builds?
Sorry I do not follow. Do you propose any changes to Boost.Test or Boost.Build?
Something similar could be done to detect calls to terminate().
Like for example?
Never mind. I just realized that this is based on too many assumptions of mine. I'll try again *after* sorting out why exactly run-fail does not do what I expect on my machine. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (4)
-
Andreas Huber -
David Abrahams -
Gennadiy Rozental -
Victor A. Wagner Jr.