Re: [Libmesh-users] LIBMESH_ENABLE_EXCEPTIONS

[John P. <jwp...@gm...>]

On Thu, Aug 27, 2015 at 11:10 AM, John Peterson <jwp...@gm...>
wrote:

>
>
> On Thu, Aug 27, 2015 at 9:53 AM, Michael Povolotskyi <mpo...@pu...>
> wrote:
>
>> Another thought.
>> In your error handler you call MPI_Abort.
>> I think this is causing problem for my application.
>> In my application I use both real and complex versions of PETSc, so I
>> initialize MPI myself, then initialize PETSC, then initialize libmesh.
>>
>
> I don't know what one is legally allowed to do (other than abort()) in a
> terminate handler, or what the state of the program even is once the
> terminate handler has been called,
>

Just to clarify, the standard is a bit vague (C++11, Section 18.8.3.1):

Type terminate_handler
> ...
> Required behavior: A terminate_handler shall terminate execution of the
> program without returning to the caller.


but I'm fairly sure this means *not* calling abort()/MPI_Abort() leads to
undefined behavior.

And now that I look at it, we are actually doing a bit more in the
terminate_handler than is 100% safe, e.g. libMesh::write_traceout() might
throw, which would lead to strangeness (in C++11, std::terminate is
declared as noexcept, which means that if you throw from it, std::terminate
is called recursively...).  Also it is generally a bad idea to mess with
global variables (e.g. libMesh::perflog) in the terminate handler, since
the initialization of yet another global may be what triggered termination
in the first place.  But I consider both of these situations to be unlikely
corner cases.

-- 
John