When I `throw` something, where is it stored in memory?

Question

I understand that when something is thrown, the stack is 'unwound' to the point where it is caught, and the destructors of class instances on the stack in each function context are run (which is why you should not throw an exception from a destructor - you could end up throwing a second one)...but I wonder where in memory the object that I have thrown is stored while this happens?

Is it implementation dependent? If so, is there a particular method used by most popular compilers?

Good question - it's probably not specified by the standard, since the standard doesn't even say that you have to have a stack. Practically, perhaps it's allocated on the heap and freed when the catch block exits? — Kerrek SB
@Kerrek: I think more likely, the object is placed on the stack way down at the "bottom". Then unwind upwards, remembering where it was, and once you've finished unwinding (including giving any catch clauses the opportunity to address the exception by reference, and to re-raise it), destroy it. The issue with heap allocation is, what do you do if your attempt to allocate the exception fails? You'd have to abort (just as you would for stack overflow if putting it on the stack "fails" due to lack of space). Unlike Java the implementation isn't allowed to throw a different exception instead. — Steve Jessop
@Steve: Also possible - Kiril's article says that the exception is allocated on the stack, and an auxiliary info structure records its address and deleter etc., but I imagine that implementations are free to do this in any way they like? — Kerrek SB
@Kerrek: yes, subject to the constraint that it has to actually throw the exception, and the usual issue that running out of stack permits the implementation to evade such responsibilities :-) If you put it on the stack, then because exceptions are thrown by the static type of the throw expression, your stack frame for the whole function could include whatever space is needed to throw that type, although I don't know if MSVC does that. — Steve Jessop

NPE NPE · Accepted Answer · 2011-07-07T14:14:29

Yes, the answer is compiler-dependent.

A quick experiment with my compiler (g++ 4.4.3) reveals that its runtime library first tries to malloc memory for the exception and, failing that, attempts to allocate space within a process-wide "emergency buffer" that lives on the data segment. If that doesn't work out, it calls std::terminate().

It would appear that the main purpose of the emergency buffer is to be able to throw std::bad_alloc after the process has run out of heap space (in which case the malloc call would fail).

The relevant function is __cxa_allocate_exception:

extern "C" void *
__cxxabiv1::__cxa_allocate_exception(std::size_t thrown_size) throw()
{
  void *ret;

  thrown_size += sizeof (__cxa_refcounted_exception);
  ret = malloc (thrown_size);

  if (! ret)
    {
      __gnu_cxx::__scoped_lock sentry(emergency_mutex);

      bitmask_type used = emergency_used;
      unsigned int which = 0;

      if (thrown_size > EMERGENCY_OBJ_SIZE)
        goto failed;
      while (used & 1)
        {
          used >>= 1;
          if (++which >= EMERGENCY_OBJ_COUNT)
            goto failed;
        }

      emergency_used |= (bitmask_type)1 << which;
      ret = &emergency_buffer[which][0];

    failed:;

      if (!ret)
        std::terminate ();
    }

  // We have an uncaught exception as soon as we allocate memory.  This
  // yields uncaught_exception() true during the copy-constructor that
  // initializes the exception object.  See Issue 475.
  __cxa_eh_globals *globals = __cxa_get_globals ();
  globals->uncaughtExceptions += 1;

  memset (ret, 0, sizeof (__cxa_refcounted_exception));

  return (void *)((char *)ret + sizeof (__cxa_refcounted_exception));
}

I don't know how typical this scheme is.

When I `throw` something, where is it stored in memory?

5 Answers