[cxx-abi-dev] A question about terminate handlers

[Marshall Clow]

On Feb 17, 2014, at 10:50 AM, John McCall <rjmccall at apple.com> wrote:

> On Feb 15, 2014, at 11:05 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
>> Consider the following code (example from Stephen T. Lajavev)
>> 
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <exception>
>> using namespace std;
>> 
>> void MyTerminate() {
>>   puts("MyTerminate()");
>>   abort();
>> }
>> 
>> int main() {
>>   try {
>>       try {
>>           puts("main() throwing int");
>>           throw 5;
>>       } catch (int) {
>>           puts("int caught initially");
>>           #ifdef MEOW
>>               puts("calling set_terminate()");
>>               set_terminate(MyTerminate);
>>           #endif
>>           puts("rethrowing");
>>           throw;
>>       }
>>   } catch (int) {
>>       puts("int caught again, calling terminate()");
>>       terminate();
>>   }
>> }
>> 
>> [ Tests on Mac OS X Mavericks  - g++11 is an alias for “g++-4.8.2 -std=c++11” ]
>> 
>> $ clang++ -std=c++11 -stdlib=libc++ -DMEOW meow.cpp && ./a.out
>> main() throwing int
>> int caught initially
>> calling set_terminate()
>> rethrowing
>> int caught again, calling terminate()
>> libc++abi.dylib: terminating with uncaught exception of type int
>> Abort trap: 6
>> $ g++11 meow.cpp -DMEOW && ./a.out
>> main() throwing int
>> int caught initially
>> calling set_terminate()
>> rethrowing
>> int caught again, calling terminate()
>> MyTerminate()
>> Abort trap: 6
>> $ 
>> 
>> Specifically:
>> 	libc++ & libc++abi call the terminate handler that was active when the exception was created.
>> 	libstdc++ and libsup++ call the terminate handler that was installed when the exception was rethrown.
>> 
>> Does the C++ ABI document have anything to say about terminate handlers being updated while an exception is in flight?
> 
> I would expect this to be controlled by the language standard, not by the ABI document.

And yet it is spelled out in the ABI document in section 2.2.2.1: (http://mentorembedded.github.io/cxx-abi/abi-eh.html)

	• The fields unexpectedHandler and terminateHandler contain pointers to the unexpected and terminate handlers at the point where the exception is thrown. The ISO C++ Final Draft International Standard [lib.unexpected] (18.6.2.4) states that the handlers to be used are those active immediately after evaluating the throw argument. If destructors change the active handlers during unwinding, the new values are not used until unwinding is complete.

Of course, “the” FDIS refers to the 2003 one, and later, there was the 2011 one, and as of last week there is a (possibly not final) 2014 DIS.

> Amusingly, the current standard is simply ungrammatical:
>  N3797 [terminate]p1:
>    Called by the implementation when exception handling must be abandoned
>    for any of several reasons, in effect immediately after throwing the exception.
> Clearly what’s “in effect” is supposed to be the terminate_handler, but...
> 
> As far as I can tell, this is a splice left over from a previous revision.  e.g.
>  C++03 [lib.terminate]p1:
>    Effect: Calls the terminate_handler function in effect immediately after evaluating
>    the throw-expression, if called by the implementation, or calls the current
>    terminate_handler function, if called by the program.
> 
> Both standards are vague about *which* throw-expression is meant when more
> than one is associated with the same exception object.  If you can get the
> committee to clarify, please ask them to consider what should happen with
> std::rethrow_exception as well.

This is LWG issue 2088: http://cplusplus.github.io/LWG/lwg-active.html#2088
Apparently this was changed right before C++11 was released (see N3242 for the actual change), and it is (as you say) confused.
The editor’s comments in n3242 reflect this confusion.

So, what we have is that C++98/03 specifies things one way, and C++11/14 (arguably) a different way.
And libc++abi implements the C++03 standard, and libsup++ (4.8) implements the C++11 standard.

— Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140218/a964cd58/attachment.html>