Re: [Boost-bugs] [Boost C++ Libraries] #2349: execution monitor and terminate()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2349: execution monitor and terminate()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-09-21 19:20:16

#2349: execution monitor and terminate()
  Reporter: Norbert Buchmuller <norbi_at_[hidden]> | Owner: rogeeff
      Type: Bugs | Status: new
 Milestone: Boost 1.37.0 | Component: test
   Version: Boost 1.36.0 | Severity: Problem
Resolution: | Keywords:

Comment(by Norbert Buchmuller <norbi_at_[hidden]>):

 Replying to [comment:1 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


 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_at_45159#L252) was true
 (as it is on my system when a SIGABRT is received), then the check for
 (source:/trunk/boost/test/impl/execution_monitor.ipp_at_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_at_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 (, independently of the presence of
 {{{std::bad_exception}}} in the throw-list), and the default
 implementation of {{{terminate_handler}}} must call {{{abort()}}}
 ( 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?

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:58 UTC