2

I find myself in a situation in which I need to exit a cross-platform C++ application immediately, without running destructors, and also without causing a crash. How can I do that?

  • exit(0) runs the destructors;
  • quick_exit(0) is not implemented in VC++;
  • abort() causes a crash;
  • _Exit(0) does not seem implemented in VC++ (or at least does not appear in MSDN);
  • the documentation of _exit(0) is unclear as to whether it calls destructors – apparently, it calls them under Windows.

I believe that I can use quick_exit under non-Windows platforms, but I am lacking a solution for VC++.

Clarification (since people ask why I wish to avoid destructors) This is an optimization scenario. I am dealing with a large application that manipulates Gigabytes of RAM, allocated in complex graphs, with several processes, numerous threads, thread-safe reference-counting, watchdogs, etc. The memory management/resource deallocation mechanism is optimized for keeping the application responsive during runtime use and/or monitor possible errors (depending on build flags), but these mechanisms are clearly overkill during shutdown, keeping the CPU very busy for many seconds, draining the battery, etc – long after we are sure that all file descriptors/handles have been closed. This makes users unhappy, so I am experimenting how to improve this, preferably without having to refactor everything.

The call quick_exit was designed specifically for such scenarios, but isn't supported by VC++. So I'm looking for an alternative for that platform.

Yoric
  • 3,348
  • 3
  • 19
  • 26
  • 2
    "Without running destructors": why would you avoid running destructors? They reaaaally often do some very important work (releasing resources). – JBL Jul 18 '14 at 09:10
  • 3
    If your C++ program exits immediately without doing any clean up, that is a crash. – Joseph Mansfield Jul 18 '14 at 09:11
  • 1
    Could you please explain the rationale for *why* you would want to do this? There may be other solutions? – Some programmer dude Jul 18 '14 at 09:11
  • Will this help? http://stackoverflow.com/a/2668098/1561026 I think it says exit won't call distructors – Hamid Alaei Jul 18 '14 at 09:15
  • @JBL: An example of why you wouldn't want to run destructors is, if the application is some kind of process regulation controller having an effect on the physical world (think nuclear reactor control ;) ). If such a program's self diagnostics detects that something went awfully wrong you can no longer make assumptions about if cleanup code wouldn't make things worse. Depending on what the program is doing, it sometimes is desireable to just terminate the process without any cleanup performed, so that system is left in its state for further diagnostics or a separate emergency shutdown take over – datenwolf Jul 18 '14 at 09:29
  • You could set an "emergency exit" boolean that can be seen by the destructors. If the flag is set, each destructor would simply return without taking any action. Seems dangerous, but that could work with exit(0). – Logicrat Jul 18 '14 at 09:36
  • @datenwolf Oh, right, then it can actually make sense. – JBL Jul 18 '14 at 09:49
  • Terminating the program by calling the function `std::exit(int)` does not destroy any objects with automatic storage duration. – Alper Jul 18 '14 at 09:58
  • The real question is: what do you mean by "not causing a crash"? No core dump? Returned status OK? – James Kanze Jul 18 '14 at 09:59
  • @Alper And that may be the simplest solution. Make all objects with static lifetime pointers to dynamically allocated objects; the destructors of dynamically allocated objects will not be called unless you explicitly delete them. Then just use `exit`. – James Kanze Jul 18 '14 at 10:00
  • @datenwolf In general (although there are exceptions), if you find an inconsistency in the internal state of your program, you want to crash. (In the case of critical systems, there should be a backup which will take over immediately.) – James Kanze Jul 18 '14 at 10:02
  • Clarified the question. This is not a crash. This is an optimization to shutdown of an existing large application in which shutdown can be very long. And the application is way too large for a refactoring that would alter the memory model, especially since it has been fine-tuned and works very well for everything except shutdown. – Yoric Jul 18 '14 at 10:08
  • @JamesKanze I think it is not very simple to properly manage all those static pointers but sure it is a solution. If possible, not to define any object with static or thread storage can be another solution. – Alper Jul 18 '14 at 10:10
  • I think from experience that it is nearly impossible to exit gracefully a complex multi-threaded application. Calling global destructors in main thread will probably crash another thread. To avoid receiving false positive crash reports from Apple we started to use _Exit() instead of exit(), but there are still a few crashes, so I would like to find a way to quit immediately without crashing other threads. – prapin Aug 31 '16 at 12:46

1 Answers1

0

use C signals as defined in signal.h it should be supported on most platforms.

You specifically should be calling a raise() with a SIGABRT or kill().

AnthonyLambert
  • 8,768
  • 4
  • 37
  • 72
  • 1
    `SIGABRT` signal will have the same effect as calling `abort` (which is implemented like this), and that will be seen as a crash by the OS (possible core dump, report as a crash by Apple for iOS app, ...). – prapin Aug 31 '16 at 12:51