Modify

Ticket #2349 (closed Bugs: worksforme)

Opened 6 years ago

Last modified 6 years ago

execution monitor and terminate()

Reported by: Norbert Buchmuller <norbi@…> Owned by: rogeeff
Milestone: Boost 1.37.0 Component: test
Version: Boost 1.36.0 Severity: Problem
Keywords: Cc:

Description

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().

Attachments

boost.test-execution_monitor-terminate-testcases.diff Download (3.6 KB) - added by Norbert Buchmuller <norbi@…> 6 years ago.
Patch to create test cases for std::bad_exception and terminate().

Change History

Changed 6 years ago by Norbert Buchmuller <norbi@…>

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

comment:1 Changed 6 years ago by rogeeff

  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.

comment:2 Changed 6 years ago by 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.

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

comment:3 Changed 6 years ago by rogeeff

  • Status changed from new to closed
  • Resolution set to 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.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.