How to destroy object created in main() after SIGSEGV

Question

I would like to know if there is any trivial way of destroying an object that was created in main() after the application just crashed (or was interrupted, or some other. See the code:

#include <iostream>
#include <signal.h>
#include <stdlib.h>

class TestClass {
public:
    TestClass() { std::cerr << "Constructor" << std::endl; }
    ~TestClass() { std::cerr << "Destructor" << std::endl; }
};

void signal_handler(int signum) {
    std::cerr << "Signal caught " << signum << std::endl;
    exit(1);
}

int main() {

    TestClass a; 

    struct sigaction new_action, old_action;
    new_action.sa_handler = signal_handler;
    sigemptyset (&new_action.sa_mask);
    new_action.sa_flags = 0;

    sigaction (SIGSEGV, NULL, &old_action);
    if (old_action.sa_handler != SIG_IGN)
    {
        sigaction (SIGSEGV, &new_action, NULL);
    }
    // CRASH !!!
    int* p = 0; *p = 0;
}

So, I install a signal handler, which upon execution shall do some cleanup, and just exit afterwards. Obviously, it is a big application, so I'd like to call the destructor of my classes which have created temporary files (theoretically speaking).

It would be easy to allocate it dynamically and in the signal_handler just free it (in order to call the destructor), but that involves some extra work.

And also, it could be a global object, but I want to avoid the global initialization order issue ...

When you receive a segmentation fault, you can't tell from inside the program what went wrong, so you can't say what you have to do to fix it. And you don't actually have to do anything, as all modern multi-tasking operating systems will free and release all resources you have allocated when the program exits anyway. — Some programmer dude, Sep 04 '14 at 11:42
@JoachimPileborg: you're right that the operating system will free memory, file handles, network connections, and some other resources. But it won't free everything, e.g. temp files, POSIX message queues, and I'm sure plenty of "legacy" resources people have which are not, shall we say, "connection-oriented." Here's a popular question I asked long ago about one such case: http://stackoverflow.com/questions/471344/guaranteed-file-deletion-upon-program-termination-c-c — John Zwinck, Sep 04 '14 at 11:46
@fritzone: is your application server-like, with a central event loop going round and round? Or is it more of a procedural, one-time-through application? — John Zwinck, Sep 04 '14 at 11:47
@JohnZwinck It's a server[-like] application handling requests from clients (in separate threads). — Ferenc Deak, Sep 04 '14 at 12:10

score 1 · Accepted Answer · edited May 23 '17 at 11:57

You could try to orchestrate an orderly shutdown on SIGSEGV. It's not without its pitfalls, but start here: Is it possible to terminate only the one thread on receiving a SIGSEGV?

You could try to terminate the one offending thread in your signal handler, and set a global flag to say "We're screwed, time to shut down." Then in your main message loop, check the flag and break out if it's set.

How to destroy object created in main() after SIGSEGV

1 Answers1