What happens if ‘throw’ fails to allocate memory for exception object?

by

(providing my own answer… I’ll wait for few days and if there are no problems with it — I’ll mark it as accepted)

I spent some time investigating this and here is what I unearthed:

  • C++ standard does not specify what is going to happen in this case
  • Clang and GCC seem to use C++ Itanium ABI

Itanimum ABI suggests to use heap for exceptions:

Storage is needed for exceptions being thrown. This storage must
persist while stack is being unwound, since it will be used by the
handler, and must be thread-safe. Exception object storage will
therefore normally be allocated in the heap

…

Memory will be allocated by the __cxa_allocate_exception runtime library routine.

So, yeah… throwing an exception will likely involve locking mutexes and searching for a free memory block. 🙁

It also mentions this:

If __cxa_allocate_exception cannot allocate an exception object under these constraints, it calls terminate()

Yep… in GCC and Clang “throw myX();” can kill your app and you can’t do a thing about it (maybe writing your own __cxa_allocate_exception can help — but it certainly won’t be portable)

It gets even better:

3.4.1 Allocating the Exception Object

Memory for an exception object will be allocated by the
__cxa_allocate_exception runtime library routine, with general requirements as described in Section 2.4.2. If normal allocation
fails, then it will attempt to allocate one of the emergency buffers,
described in Section 3.3.1, under the following constraints:

  • The exception object size, including headers, is under 1KB.
  • The current thread does not already hold four buffers.
  • There are fewer than 16 other threads holding buffers, or this thread
    will wait until one of the others releases its buffers     before acquiring one.

Yep, your program can simply hang! Granted chance of this are small — you’d need to exhaust memory and your threads need to use up all 16 emergency buffers and enter wait for another thread that should generate an exception. But if you do things with std::current_exception (like chaining exception and passing them between threads) — it is not so improbable.

Conclusion:

This is a deficiency in C++ standard — you can’t write 100% reliable programs (that use exceptions). Text book example is a server that accepts connections from clients and executes submitted tasks. Obvious approach to handle problems would be to throw an exception, which will unwind everything and close connection — all other clients won’t be affected and server will continue to operate (even under low memory conditions). Alas, such server is impossible to write in C++.

You can claim that modern systems (i.e. Linux) will kill such server before we reach this situation anyway. But (1) it is not an argument; (2) memory manager can be set to overcommit; (3) OOM killer won’t be triggered for 32-bit app running on 64bit hardware with enough memory (or if app artificially limited memory allocation).

On personal note I am quite pissed about this discovery — for many years I claimed that my code handles out-of-memory gracefully. Turns out I lied to my clients. 🙁 Might as well start intercepting memory allocation, call std::terminate and treat all related functions as noexcept — this will certainly make my life easier (coding-wise). No wonder they still use Ada to programs rockets.

More Related Contents:

  1. Error while passing vector to instance of object in main
  2. Concurrency: Atomic and volatile in C++11 memory model
  3. const vs constexpr on variables
  4. The new syntax “= default” in C++11
  5. What is a subnormal floating point number?
  6. Pointers in c++ after delete
  7. Why does std::move prevent RVO (return value optimization)?
  8. Why are by-value parameters excluded from NRVO?
  9. What is the difference between packaged_task and async
  10. Populate An Array Using Constexpr at Compile-time
  11. Exception safety and make_unique
  12. Why should I use std::async?
  13. How to use C++11 enum class for flags
  14. std::pow produce different result in 32 bit and 64 bit application
  15. Double delete in initializer_list vs 2013
  16. What’s the point of a final virtual function?
  17. C++ terminate called without an active exception
  18. How to enforce the ‘override’ keyword?
  19. C++11 operator”” with double parameter
  20. std::remove_const with const references
  21. Uniform initialization fails to copy when object has no data members
  22. reinterpret_cast between char* and std::uint8_t* – safe?
  23. Check if a type is from a particular namespace
  24. How to get the precision of high_resolution_clock?
  25. How does =delete on destructor prevent stack allocation?
  26. c++11 Thread class how to use a class member function
  27. C++11 ‘native_handle’ is not a member of ‘std::this_thread’
  28. Does C++11 unique_ptr and shared_ptr able to convert to each other’s type?
  29. Proper way to receive a lambda as parameter by reference
  30. When to use functors over lambdas

Leave a Comment