[Gc] workaround for C++ exceptions problem

skaller skaller at users.sourceforge.net
Tue Jan 24 22:10:24 PST 2006

On Tue, 2006-01-24 at 22:58 -0500, Filip Pizlo wrote:
> On Jan 24, 2006, at 10:43 PM, skaller wrote:

> > No. at the point you mention NO exceptions are 'in flight'.
> > BOTH of them have already 'landed'.
> I figured it wasn't the right terminology to use, but assumed  
> everyone would know what I meant.  The point is that the exception  
> objects and their types are being managed by the C++ runtime.

That isn't clear though: when an exception is caught,
who knows what happens to it?

> > In flight means 'taken off but not landed', that is:
> > thrown but not caught.
> Thanks for the clarification.

Lol .. that was just my definition :)

Lets just look at Hans proposal to copy the 'current'
exception object on the assumption it is unique: I think
my point is that can't work.

What I expect to happen is explained as follows. Multiple
exceptions in flight arise because unwinding is recursive.
During unwinding .. which pops the stack .. it is necessary
to destroy the stacked objects before actually popping the
stack pointer.

The process of destroying those objects may itself use
local variables, that is, it can push data onto the stack.
So inside this context, the code acts quite normally,
AS IF there were no exception in flight. In particular,
you can throw an exception and it will fire off just fine,
and start unwinding the stack.

If you catch it inside that context .. all continues exactly
as normal. There is a problem if the exception keeps propagating
outside the context of the routine destroying the stack,
so there has to be a check at this point somehow.

Now in particular, the original exception is probably
pushed onto the stack, and the slot for holding the
current exception is cleared, so that any new exception
can be stored there .. that is, the system is in the
state that looks like no exception is in flight.

In particular that pushed exception is now ON the stack
and so the GC can find it without it being a root.

Note: I'm guessing -- other possibilities exist,
such as not clearing that location until a new throw
actually happens. Or, it may use some other
storage as the stack (could be useful if the error
was due to 'out of stack space' .. :)

It seems to me there is even worse to come if you try
to track the exception state.

OTOH your original suggestion seems better to me!

By hooking the allocation, it matters not whether
or when the deallocation occurs -- as long as the hook catches
all allocations and deallocations and passes them on
to the gc.

Even this may not work! As I understand it these are
root objects which are scanable but not collectable.
So what happens if somehow the pointer is stored
somewhere reachable and lost by the EH mechanism?
I have no idea if this can happen -- probably NOT
in ISO C++, but it is hard to be sure without one's
brain throwing a double fault :)

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: https://felix.sf.net

More information about the Gc mailing list