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

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?

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.

From this page:

> 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, although > implementations may provide an > emergency buffer to support throwing > bad_alloc exceptions under low memory > conditions.

Now, this is only the Itanium ABI and I'm looking for details specific to GCC, Clang and MSVC. However, the standard doesn't specify anything and this seems to be the obvious way to implement exception storage, so...

I don't know if this will answer your question, but this (How a C++ compiler implements exception handling) is excellent article about the exception handling at all: . I highly recommend it (:

Sorry for the short answer, but the whole information in the article is great, I can't pick and post some info here.

The C++ standard generally specifies how the language behaves but not how the compiler should implement that behavior. I think this question falls into that category. The best way to implement something like this depends on the specifics of the machine -- some processors have lots of general purpose registers, some have very few. A processor might even be built with a special register just for exceptions, in which case the compiler should be free to take advantage of that feature.

Well, it can't be on the stack, since that's going to be unwound, and it can't be on the heap, since that would mean that the system likely couldn't throw std::bad_alloc. Other than that, it's completely up to the implementation: not implementation specified (which must be documented), but unspecified. (An implementation could use the heap most of the time, as long as it has some sort of emergency back-up that will allow a limited number of exceptions even when there's no more memory.)