CertC++-ERR57

Do not leak resources when handling exceptions

Required inputs: IR, StaticSemanticAnalysis

Reclaiming resources when exceptions are thrown is important. An exception being thrown may result in cleanup code being bypassed or an object being left in a partially initialized state. Such a partially initialized object would violate basic exception safety, as described in ERR56-CPP. Guarantee exception safety. It is preferable that resources be reclaimed automatically, using the RAII design pattern [ Stroustrup 2001], when objects go out of scope. This technique avoids the need to write complex cleanup code when allocating resources.

However, constructors do not offer the same protection. Because a constructor is involved in allocating resources, it does not automatically free any resources it allocates if it terminates prematurely. The C++ Standard, [except.ctor], paragraph 2 [ ISO/IEC 14882-2014], states the following:

An object of any storage duration whose initialization or destruction is terminated by an exception will have destructors executed for all of its fully constructed subobjects (excluding the variant members of a union-like class), that is, for subobjects for which the principal constructor (12.6.2) has completed execution and the destructor has not yet begun execution. Similarly, if the non-delegating constructor for an object has completed execution and a delegating constructor for that object exits with an exception, the object's destructor will be invoked. If the object was allocated in a new-expression, the matching deallocation function (3.7.4.2, 5.3.4, 12.5), if any, is called to free the storage occupied by the object.

It is generally recommended that constructors that cannot complete their job should throw exceptions rather than exit normally and leave their object in an incomplete state [ Cline 2009].

Resources must not be leaked as a result of throwing an exception, including during the construction of an object.

This rule is a subset of  MEM51-CPP. Properly deallocate dynamically allocated resources, as all failures to deallocate resources violate that rule.

Noncompliant Code Example

In this noncompliant code example, pst is not properly released when  process_item throws an exception, causing a resource leak. 

#include <new>
 
struct SomeType {
  SomeType() noexcept; // Performs nontrivial initialization.
  ~SomeType(); // Performs nontrivial finalization.
  void process_item() noexcept(false);
};
 
void f() {
  SomeType *pst = new (std::nothrow) SomeType();
  if (!pst) {
    // Handle error
    return;
  }
 
  try {
    pst->process_item();
  } catch (...) {
    // Process error, but do not recover from it; rethrow.
    throw;
  }
  delete pst;
}
Compliant Solution ( delete)

In this compliant solution, the exception handler frees  pst by calling  delete. 

#include <new>

struct SomeType {
  SomeType() noexcept; // Performs nontrivial initialization.
  ~SomeType(); // Performs nontrivial finalization.

  void process_item() noexcept(false);
};

void f() {
  SomeType *pst = new (std::nothrow) SomeType();
  if (!pst) {
    // Handle error
    return;
  }
  try {
    pst->process_item();
  } catch (...) {
    // Process error, but do not recover from it; rethrow.
    delete pst;
    throw;
  }
  delete pst;
}

While this compliant solution properly releases its resources using catch clauses, this approach can have some disadvantages:

  • Each distinct cleanup requires its own try and catch blocks.
  • The cleanup operation must not throw any exceptions.
Compliant Solution (RAII Design Pattern)

A better approach is to employ RAII. This pattern forces every object to clean up after itself in the face of abnormal behavior, preventing the programmer from having to do so. Another benefit of this approach is that it does not require statements to handle resource allocation errors, in conformance with  MEM52-CPP. Detect and handle memory allocation errors. 

struct SomeType {
  SomeType() noexcept; // Performs nontrivial initialization.
  ~SomeType(); // Performs nontrivial finalization.

  void process_item() noexcept(false);
};

void f() {
  SomeType st;
  try {
    st.process_item();
  } catch (...) {
    // Process error, but do not recover from it; rethrow.
    throw;
  } // After re-throwing the exception, the destructor is run for st.
} // If f() exits without throwing an exception, the destructor is run for st.
Noncompliant Code Example

In this noncompliant code example, the  C::C() constructor might fail to allocate memory for  a, might fail to allocate memory for  b, or might throw an exception in the  init() method. If  init() throws an exception, neither  a nor  b will be released. Likewise, if the allocation for  b fails, a will not be released. 

struct A {/* ... */};
struct B {/* ... */};

class C {
  A *a;
  B *b;
protected:
  void init() noexcept(false);
public:
  C() : a(new A()), b(new B()) {
    init();
  }
};
Compliant Solution ( try/catch)

This compliant solution mitigates the potential failures by releasing  a and  b if an exception is thrown during their allocation or during  init(). 

struct A {/* ... */};
struct B {/* ... */};
 
class C {
  A *a;
  B *b;
protected:
  void init() noexcept(false);
public:
  C() : a(nullptr), b(nullptr) {
    try {
      a = new A();
      b = new B();
      init();
    } catch (...) {
      delete a;
      delete b;
      throw;
    }
  }
};
Compliant Solution (std::unique_ptr)

This compliant solution uses std::unique_ptr to create objects that clean up after themselves should anything go wrong in the  C::C() constructor. The  std::unique_ptr applies the principles of RAII to pointers. 

#include <memory>
 
struct A {/* ... */};
struct B {/* ... */};

class C {
  std::unique_ptr<A> a;
  std::unique_ptr<B> b;
protected:
  void init() noexcept(false);
public:
  C() : a(new A()), b(new B()) {
    init();
  }
};
Risk Assessment

Memory and other resource leaks will eventually cause a program to crash. If an attacker can provoke repeated resource leaks by forcing an exception to be thrown through the submission of suitably crafted data, then the attacker can mount a denial-of-service attack.

Rule Severity Likelihood Remediation Cost Priority Level
ERR57-CPP Low Probable High P2 L3
Related Guidelines
SEI CERT C++ Coding Standard MEM51-CPP. Properly deallocate dynamically allocated resources
 MEM52-CPP. Detect and handle memory allocation errors
 ERR56-CPP. Guarantee exception safety  
Bibliography
[ Cline 2009] Question 17.2, I'm still not convinced: A 4-line code snippet shows that return-codes aren't any worse than exceptions;
why should I therefore use exceptions on an application that is orders of magnitude larger?
[ ISO/IEC 14882-2014] Subclause 15.2, "Constructors and Destructors"
[ Meyers 1996] Item 9, "Use Destructors to Prevent Resource Leaks"
[ Stroustrup 2001] "Exception-Safe Implementation Techniques"
Excerpt from SEI CERT C++ Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-cpp-coding-standard/rules/exceptions-and-error-handling-err/err57-cpp], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key

Text

Severity

Disabled

memory_leak

Call allocates leaking memory

None

False

possible_memory_leak

Call allocates possibly leaking memory

None

False

Options

resources

resources

Type: set[str]

Default: {'C++HeapMemory', 'CudaAsyncMemory', 'CudaDeviceMemory', 'CudaDriverAsyncMemory', 'CudaHostMemory', 'CudaManagedMemory', 'HeapMemory', 'UniquePtrHeapMemory'}

Set of resources to be checked (selection of rules in the Resources group).
 

witness_paths

witness_paths : bool = True

Whether witness paths should be determined and included in the issue.
 

witness_should_include_exception_handling

witness_should_include_exception_handling : bool = True

Whether to only accept witness paths that include some kind of exception handling.