Hello again, after some break I got again to the code debugging. The only solution to avoid calling libmesh handler was to use std::set_terminate(NULL) after libmesh initialization.
With this the MPI_Abort is not called anymore, which is good, but the standard handler of Intel C++ compiler is not called either, which is not good. I do not know how to reset the standard handler, and, I'm afraid, this can be a compiler dependent instruction. So, the only solution I see now is to hack your code in my local repository - otherwise we cannot work as we were working before. Can you add a possibility to configure libmesh such that the handler is not changed at all? Regards, Michael. On 08/31/2015 04:40 PM, Roy Stogner wrote: > > On Mon, 31 Aug 2015, Michael Povolotskyi wrote: > >> Why do you put the error handler inside the library? > > As with every other "Why do you put X inside libmesh?" question, > it's a combination of good sense (useful stuff should go in *some* > library to get reused) and laziness (error handling isn't > FEM-specific, so it could go in a separate library and be useful to > more than libMesh users, but we haven't yet figured out a good way to > separate out all our more-general library components without adding > more work for libMesh developers). > >> Imagine that my application has many libraries, each of them has its >> own handler, how this should work together? > > Take a look inside libmesh_terminate_handler() (and at the > set_terminate call in the same file). When installing our handler, we > save the pre-existing handler, and then the last thing our handler > does is to call that pre-existing handler. > > If other libraries behave this way, then everything works together: > you initialize libraries A, B, C, then D; this leaves the C++ > terminate handler set to handler_D, which then calls handler_C, which > then calls handler_B, which then calls handler_A. > > If you want to do this with parallel libraries, then you run into one > more problem: in a crash someone should call MPI_Abort() (to prevent > runs from just hanging and burning CPU time on large systems), but > calling MPI_Abort() kills the program before it can ever get to an > older terminate handler. In this case the solution is to either make > sure there is no older terminate handler (make libMesh the first > library you initialize) or handle MPI yourself (call MPI_Init() before > constructing LibMeshInit, and we'll detect that we're not in charge of > MPI, so we won't ever call MPI_Init or MPI_Abort) and install your own > handler_A that does MPI_Abort only after everyone else's handler is > done. > >> It is convenient that libmesh throws exceptions that explain what went >> wrong. >> Still I'd like to catch them in my application, not in the library. > > This requirement is actually the reason *why* we use C++ exceptions > instead of a simpler abort(). > > If you wrap libMesh operations in a try/catch block, you can catch > anything libMesh throws, and the terminate handler never gets called. > In C++ the terminate handler *only* gets called if an exception was > uncaught: i.e. it was not called from a try block, or the exception > type doesn't match the specification you give "catch". Setting a > terminate handler does *not* prevent your application from catching > exceptions. > > Now, in practice I'm not sure how useful this is. We usually only > throw exceptions when something has gone horribly unexpectedly wrong > or when there's been a convergence failure that the solver can't find > any allowable way to recover from, and in the former case it's hard to > say how much recovery you can do. In my own applications I've merely > used try/catch blocks to output restart files before exiting. That > was useful for getting checkpoint files when the solver was being > overtaxed, but it would have been a *lot* more complicated to do > anything useful in the case of e.g. an MPI desynchronization. > --- > Roy -- Michael Povolotskyi, PhD Research Assistant Professor Network for Computational Nanotechnology Hall for Discover and Learning Research, Room 441 West Lafayette, IN 47907 Phone (765) 4949396 ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
