Page History

The std::abort(), std::quick_exit(), and std::_Exit() functions are used to terminate the program in an immediate fashion. They do so without calling exit handlers registered with std::atexit(), and without executing destructors for objects with automatic, thread, or static storage duration. It How a system manages open streams when a program ends is implementation-defined as to whether open [ISO/IEC 9899:1999]. Open streams with unwritten buffered data are may or may not be flushed, open streams are may or may not be closed, or temporary files are removed [ISO/IEC 9899:1999]. Because and temporary files may or may not be removed. Because these functions can leave external resources, such as files and network communications, in an indeterminate state, they should only be called explicitly only in direct response to a critical error in the application. (See ERR50-CPP-EX1 for more information.)

The std::terminate() function calls the current terminate_handler function, which defaults to calling std::abort().

The C++ Standard defines several ways in which std::terminate() may be called implicitly by an implementation [ISO/IEC 14882-2014]:

1. When the exception handling mechanism, after completing the initialization of the exception object but before activation of a handler for the exception, calls a function that exits via an exception

...

1. ([except.throw], paragraph 7)
   
   • See ERR60-CPP. Exception objects must be nothrow copy constructible for more information.
2. When a throw-expression with no operand attempts to rethrow an exception and no exception is being handled

...

1. ([except.throw], paragraph 9)
2. When the exception handling mechanism cannot find a handler for a thrown

...

1. exception ([except.handle], paragraph 9)
   • See ERR51-CPP. Handle all exceptions for more information.
2. When the search for a handler encounters the outermost block of a function with a noexcept-specification that does not allow the exception

...

1. ([except.spec], paragraph 9)
   • See 

...

1. • ERR55-CPP. Honor exception specifications for more information.
2. When the destruction of an object during stack unwinding terminates by throwing an exception

...

1. ([except.ctor], paragraph 3)
   • See DCL57-CPP. Do not let exceptions escape from destructors or deallocation functions for more information.
2. When initialization of a

...

1. nonlocal variable with static or thread storage duration exits via an exception

...

1. ([basic.start.init], paragraph 6)
   
   • See 

...

1. • ERR58-CPP.

...

1. • Handle all exceptions thrown before main() begins executing for more information.
2. When destruction of an object with static or thread storage duration exits via an exception

...

1. ([basic.start.term], paragraph 1)
   • See DCL57-CPP. Do not let exceptions escape from destructors or deallocation functions for more information.
2. When execution of a function registered with std::atexit()

...

1. or std::at_quick_exit() exits via an exception

...

1. ([support.start.term], paragraphs 8 and 12)
2. When the implementation’s default unexpected exception handler is called

...

1. ([except.unexpected], paragraph 2)
   Note that std::unexpected() is currently deprecated

...

1. .
2. When std::unexpected() throws an exception

...

1. that is not allowed by the previously violated dynamic-exception-specification, and std::bad_exception() is not included in that dynamic-exception-specification

...

1. ([except.unexpected], paragraph 3)
   
2. When the function std::nested_exception::rethrow_nested() is called for an object that has captured no exception

...

1. ([except.nested], paragraph 4)
   
2. When execution of the initial function of a thread exits via an exception

...

1. ([thread.thread.constr], paragraph 5)
   • See ERR51-CPP. Handle all exceptions for more information.
2. When the destructor is invoked on an object of type std::thread that refers to a joinable thread

...

1. ([thread.thread.destr], paragraph 1)
2. When the copy assignment operator is invoked on an object of type std::thread that refers to a joinable thread

...

1. ([thread.thread.assign], paragraph 1)
   
2. When calling condition_variable::wait(), condition_variable::wait_until(), or condition_variable::wait_for() results in a failure to meet the

...

1. postcondition: lock.owns_lock() == true or lock.mutex() is not locked by the calling thread

...

1. ([thread.condition.condvar], paragraphs 11, 16, 21, 28, 33, and 40)
2. When calling condition_variable_any::wait(), condition_variable_any::wait_until(), or condition_variable_any::wait_for() results in a failure to meet the

...

1. postcondition: lock is not locked by the calling thread

...

1. ([thread.condition.condvarany], paragraphs 11, 16, and 22)

In many circumstances, the call stack will not be unwound in response to the an implicit call to std::terminate(), and in a few cases, it is implementation-defined as to whether or not stack unwinding will occur or not. The C++ Standard, [except.terminate], paragraph 2 [ISO/IEC 14882-2014], in part, states , in partthe following:

In the situation where no matching handler is found, it is implementation-defined whether or not the stack is unwound before std::terminate() is called. In the situation where the search for a handler encounters the outermost block of a function with a noexcept-specification that does not allow the exception, it is implementation-defined whether the stack is unwound, unwound partially, or not unwound at all before std::terminate() is called. In all other situations, the stack shall not be unwound before std::terminate() is called.

Do not allow an implicit call to explicitly or implicitly call std::quick_exit(),  std::abort(), or std::_Exit(). When the default terminate_handler is installed , or the current terminate_handler responds by calling std::abort() or std::_Exit(), do not allow an implicit call to explicitly or implicitly call std::terminate(). Abnormal  Abnormal process termination is the typical vector for denial-of-service  attacksattacks.It is acceptable to call 

The std::abort(), std::_Exit(), or std::terminate() in response to a critical program error for which no recovery is possible, after indicating the nature of the problem to the operator. See also ERR04-CPP. Choose an appropriate termination strategy.exit() function is more complex. The C++ Standard, [basic.start.main], paragraph 4, states:

Terminating the program without leaving the current block (e.g., by calling the function std::exit(int) (17.5)) does not destroy any objects with automatic storage duration (11.4.6). If std::exit is called to end a program during the destruction of an object with static or thread storage duration, the program has undefined behavior.

You may call std::exit() only in a program that has not yet initialized any objects with automatic storage duration.

Noncompliant Code Example

In this noncompliant code example, the call to C::to f() may result in an exception being thrown. Since C::f() is called from a destructor, this can , which was registered as an exit handler with std::at_exit(), may result in a call to std::terminate() if a non-local object of type C has static or thread storage duration, or if an object of type C is destroyed during stack unwinding (as in this example) because throwing_func() may throw an exception.

class C {
  void f#include <cstdlib>
 
void throwing_func() noexcept(false);
 
public:
  ~Cvoid f() { f(); }
};
 
void throwing_func() noexcept(false);
 
void f() noexcept(false) {
  C c;// Not invoked by the program except as an exit handler.
  throwing_func();
}
 
voidint gmain() noexcept(true) {
  tryif {
(0    f();
  } catch (...!= std::atexit(f)) {
    // Handle error
  }
}

If throwing_func() throws an exception, f() does not attempt to catch it and it will be handled by g(). However, during stack unwinding to reach the exception handler in g(), the automatic local variable c will be destroyed, resulting in a call to C::~C(). When the destructor attempts to throw an exception, std::terminate() will be called instead of throwing.

Note, the declaration for C::~C() does not comply with DCL40-CPP. Destructors and deallocation functions must be declared noexcept because destructors are implicitly declared noexcept(true), and this destructor allows exceptions by virtue of calling a function marked noexcept(false).

  // ...
}

Compliant Solution

In this compliant solution, the destructor for C  f() handles all exceptions and does not rethrow. When the automatic local variable c is destroyed, no exception is triggered from the C::~C() call, and the exception thrown by throwing_func() will be caught by the handler in g() and does not rethrow.

class C {
  void f#include <cstdlib>

void throwing_func() noexcept(false);
 
public:
void  ~Cf() {
   // Not invoked by the program except as an exit handler.
  try {
      fthrowing_func();
    } catch (...) {
      // Handle error
    }
  }
};
 
void throwing_funcint main() noexcept(false);
 
void f() noexcept(false) {
  C c;
  throwing_func();
}
 
void g() noexcept(trueif (0 != std::atexit(f)) {
  try {
 // Handle  f();error
  } catch (...) {
    // Handle error
  }...
}

Noncompliant Code Example

Exceptions

ERR50-CPP-EX1: It is acceptable, after indicating the nature of the problem to the operator, to explicitly call std::abort(), std::_Exit(), or std::terminate() in response to a critical program error for which no recovery is possible, as in this example.In this noncompliant code example, the call to f(), which was registered as an exit handler with std::at_exit(), may result in a call to std::terminate() because throwing_func() may throw an exception:

#include <cstdlib><exception>
 
void throwing_func(report(const char *msg) noexcept(false);
 
[[noreturn]] void f(fast_fail(const char *msg) {
  throwing_func();
}
 
int main() {
  if (0 != std::at_exit(f)) {
    // Handle error
  }
  // ...
}

Compliant Solution

In this compliant solution, f() handles all exceptions thrown by throwing_func(), and does not rethrow:

#include <cstdlib>

void throwing_func// Report error message to operator
  report(msg);
 
  // Terminate
  std::terminate();
}
 
void critical_function_that_fails() noexcept(false);
 
void f() {
  try {
    throwing_funccritical_function_that_fails();
  } catch (...) {
    // Handle errorfast_fail("Critical function failure");
  }
}

int main() {
  if (0 != std::at_exit(f)) {
    // Handle error
  }
  // ...
}

The assert() macro is permissible under this exception because failed assertions will notify the operator on the standard error stream in an implementation-defined manner before calling std::abort().

Risk Assessment

Allowing the application to abnormally terminate in an implicit manner can lead to resources not being freed, closed, etcand so on. It is frequently a vector for denial-of-service attacks.

Automated Detection

Related Vulnerabilities

Search for other vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified