Is destructor called if SIGINT or SIGSTP issued?

by

No, by default, most signals cause an immediate, abnormal exit of your program.

However, you can easily change the default behavior for most signals.

This code shows how to make a signal exit your program normally, including calling all the usual destructors:

#include <iostream>
#include <signal.h>
#include <unistd.h>
#include <cstring>
#include <atomic>

std::atomic<bool> quit(false);    // signal flag

void got_signal(int)
{
    // Signal handler function.
    // Set the flag and return.
    // Never do real work inside this function.
    // See also: man 7 signal-safety
    quit.store(true);
}

class Foo
{
public:
    ~Foo() { std::cout << "destructor\n"; }
};

int main(void)
{
    struct sigaction sa;
    memset( &sa, 0, sizeof(sa) );
    sa.sa_handler = got_signal;
    sigfillset(&sa.sa_mask);
    sigaction(SIGINT,&sa,NULL);

    Foo foo;    // needs destruction before exit
    while (true)
    {
        // do real work here...
        sleep(1);
        if( quit.load() ) break;    // exit normally after SIGINT
    }
    return 0;
}

If you run this program and press control-C, you should see the word “destructor” printed.

Be aware that your signal handler function (got_signal) should rarely do any work, other than setting a flag and returning quietly, unless you really know what you are doing. See also: https://man7.org/linux/man-pages/man7/signal-safety.7.html

Most signals are catchable as shown above, but not SIGKILL, you have no control over it because SIGKILL is a last-ditch method for killing a runaway process, and not SIGSTOP which allows a user to freeze a process cold. Note that you can catch SIGTSTP (control-Z) if desired, but you don’t need to if your only interest in signals is destructor behavior, because eventually after a control-Z the process will be woken up, will continue running, and will exit normally with all the destructors in effect.

More Related Contents:

  1. C++ – destructors [closed]
  2. Dynamically allocating an array of objects
  3. shared_ptr magic :)
  4. Pure virtual destructor in C++
  5. Object destruction in C++
  6. Is calling destructor manually always a sign of bad design?
  7. calling destructor explicitly
  8. How can I catch a ctrl-c event?
  9. Do I need to explicitly call the base virtual destructor?
  10. Why is the destructor of the class called twice?
  11. When is an object “out of scope”?
  12. GNU GCC (g++): Why does it generate multiple dtors?
  13. Does std::list::remove method call destructor of each removed element?
  14. Forward declaration with unique_ptr? [duplicate]
  15. Is it possible to delete a non-new object?
  16. Destructors of builtin types (int, char etc..)
  17. Is a Union Member’s Destructor Called
  18. Will an ’empty’ constructor or destructor do the same thing as the generated one?
  19. Is a destructor called when an object goes out of scope?
  20. What destructors are run when the constructor throws an exception?
  21. C++ local variable destruction order
  22. Why do un-named C++ objects destruct before the scope block ends?
  23. Why, really, deleting an incomplete type is undefined behaviour?
  24. Creating an object: with or without `new` [duplicate]
  25. Pseudo-destructor call does not destroy an object
  26. Why destructor is not called on exception?
  27. Why does destructor disable generation of implicit move methods?
  28. Observable behavior and undefined behavior — What happens if I don’t call a destructor?
  29. Is the whole object freed with a non-virtual destructor and a Base class pointer?
  30. C++ Constructor/Destructor inheritance

Leave a Comment