On Thu, Aug 27, 2015 at 11:10 AM, John Peterson <jwpeter...@gmail.com> wrote:
> > > On Thu, Aug 27, 2015 at 9:53 AM, Michael Povolotskyi <mpovo...@purdue.edu> > 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 ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
