execution monitor and terminate()

[Norbert Buchmuller <norbi@…>]

In versions 1.35.0 and 1.36.0 the execution monitor does not detect if terminate() is called. In the current trunk (r48903) it does, but still does not have any test cases for this condition (so I think it was fixed without knowing the problem). I think a test case would be useful to detect regressions.

I noticed this problem with GCC 3.4.6 and GCC 4.1.2 on i486-linux-gnu. These compilers always call terminate() from unexpected() (ie. they call terminate() even if std::bad_exception is in the throw-list), and terminate() calls abort().

[Norbert Buchmuller <norbi@…>]

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

[Gennadiy Rozental]

1. I don't remember changing anything in this area. Can you pinpoint specific revision?
2. 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.

[Norbert Buchmuller <norbi@…>]

Replying to rogeeff:

1. 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.

2. 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?

[Gennadiy Rozental]

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.