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

 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_at_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_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 (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?

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/2349#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.