attachment set

Sat, 20 Sep 2008 10:18:05 GMT

attachment → boost.test-execution_monitor-terminate-testcases.diff

Patch to create test cases for std::bad_exception and terminate().

Gennadiy Rozental — Sun, 21 Sep 2008 08:12:22 GMT

I don't remember changing anything in this area. Can you pinpoint specific revision?
I don't see a point of your tests. Both produce the result. Maybe if first one setup custom re-throwing unexpected handler, it would make sence. Though I still don't see what exactly we are testing here.

Sun, 21 Sep 2008 19:20:15 GMT

Replying to rogeeff:

I don't remember changing anything in this area. Can you pinpoint specific revision?

In fact the unexpected exception was just a red herring: the problem is that in 1.36.0 (as compiled on my machine) the SIGABRT signal is not detected by the Program Execution Monitor, as later I discovered that test/prg_exec_fail3.cpp fails, too:

prg_exec_fail3: ../../libs/test/test/prg_exec_fail3.cpp:22: int cpp_main(int, char**): Assertion `div != 0' failed.
no errors detected
EXIT STATUS: 0

Regarding the change that fixed the bug, it was in r45160. Previously if the check for m_sig_info->si_code <= 0 (source:/trunk/boost/test/impl/execution_monitor.ipp@45159#L252) was true (as it is on my system when a SIGABRT is received), then the check for SIGABRT (source:/trunk/boost/test/impl/execution_monitor.ipp@45159#L278) was not run (as it was in the else branch). And, as the value of m_sig_info->si_code did not match any of the case labels in the then branch (source:/trunk/boost/test/impl/execution_monitor.ipp@45159#L253), it did not reported it as an error.

The good news is that now it's fixed in trunk.

I don't see a point of your tests. Both produce the result. Maybe if first one setup custom re-throwing unexpected handler, it would make sence. Though I still don't see what exactly we are testing here.

Well, the first test (test/prg_exec_fail5.cpp) is useless in fact. I was misled by Stroustrup's book: it says (though a bit ambiguously) that if I add std::bad_exception to the throw-list then the unexpected exception will be mapped to std::bad_exception by the default unexpected_handler implementation (The C++ Programming Language 3rd ed., 14.6.3). In fact he just forgot to emphasize that you must provide a new unexpected_handler that simply throws std::bad_exception for this to work.

I looked it up in ISO/IEC 14882:2003(E), and the default implementation of unexpected_handler must call terminate() indeed (18.6.2.2/3, independently of the presence of std::bad_exception in the throw-list), and the default implementation of terminate_handler must call abort() (18.6.3.1/3). So, sorry for the noise. :-)

Now, both unexpected() (see above) and assert() (ISO/IEC 9899:1990(E) 7.2/2) terminates the program using abort() and there's already a test case for assert(), so there's no need for one more test case - unless we care about NDEBUG (ISO/IEC 9899:1990(E) 7.2/1). Do we?

status changed; resolution set

Gennadiy Rozental — Sun, 28 Sep 2008 11:56:36 GMT

status new → closed
resolution → worksforme

No. I think we fine.

As for std::bad_exception - you just need to register re-throwing handler (throw; as the only statement inside) to cause bad std::bad_exception, but this is not really what I should be testing for.

Boost C++ Libraries: Ticket #2349: execution monitor and terminate()

attachment set

status changed; resolution set