Consistant Way to Catch C++ Library Crashes

Question

I've looked around at different sites, and cannot find any answer to this question, other than ones that don't seem that they would work. As the title says, I am trying to find a way to catch if the library I am working on crashes. I have a Root class that holds instances of the many manager-style classes that I have in my library, and it releases the instances in it's destructor. Naturally, the managers are responsible for quite a bit of data, so if they are not properly disposed of there is a chance for a rather unacceptable, even dangerous level of memory leaks.

I am aware that, when a program crashes, that the OS will deallocate the stack space for the program, but that does not include calling the destructors of the allocated objects. It also does not include deleting any of the heap allocated during the execution, which is how I am dealing with a good deal of the memory in my library, which goes back to problem of widespread memory leaks.

A good deal of the answers I am coming across on other sites are just saying to register a function with atexit(), but that function does not work if the application crashes. And, as stated above, since crashes do not call destructors, there is no way to make a global singleton that closes everything when it is destroyed, which was my initial idea of how to deal with this. My other idea was to just hope that the end user of the library will take the proper precautions to avoid crashes (through widespread use of exception throwing), but I feel that goes against the idea of a well-coded library, and frankly I think it's asking a bit much of the end user to deal with that.

So I guess my TL;DR question is this: Is there a way, either through a standard C++ function, or through some sort of manager class, to catch when a library crashes and deal with it appropriately?

EDIT: Also, I would really prefer a cross platform way to deal with this. My code base heavily uses features of C++11, so I've programatically limited the useable compilers to the latest versions of GCC and Clang.

Not only that, but I also have a couple of classes, like a Logger, that will close their stream to the filesystem and print out a couple of messages about the exit status. I also have a memory tracker that reports any possible memory leaks to a file, but only in it's destructor.

Answer 1

So I guess my TL;DR question is this: Is there a way, either through a standard C++ function, or through some sort of manager class, to catch when a library crashes and deal with it appropriately?

In the presence of things like structured exception handling and various segmentation faults and bus errors (the standard saying nothing about any of these things), the only way to prevent a crash in your library from taking down a user's application is to provide the library via a binary that the client program executes, and have the client be responsible for monitoring if the client process dies.

If you want the library to be linked directly into the user's application there is nothing you can do to absolutely be sure that a bug in your library won't crash the user's application. That's what unit, subsystem, and system test suites are for. Keep in mind that if your library crashes an application pretty much every OS I'm aware of will reclaim all the resources it allocated, so you don't need a global singleton to release heap memory: It will automatically be claimed by the OS at the point of the crash.

Finally note that if the library crashes the process is already in a bad state. There is no way that you can safely execute any code (for example what if the process heap is corrupt) at the point, including writing log messages or dumping a memory leak status.

Answer 2

"Is there a way, either through a standard C++ function, or through some sort of manager class, to catch when a library crashes and deal with it appropriately?"

The most concise answer for your question I can imagine is:

Stick with the classes and categories of the C++ Standard Error handling.

---

As you are asking for atexit(), the behaviour is well defined in the standard reference as well.

Note there are further handler mechanisms like the std::terminate_handler, that allow you to handle some exceptional abort situations, in a portable and standard compliant way.

Last but not least it might be necessary to install certain (OS specific) signal handlers, to catch up errors like a so called segmentation fault (SIGSEV) raised due to stack overflow or similar things.