Re: [Pnet-developers] Re: [DotGNU] Bug in Pnet

[Russell Stuart]

On Tue, 2006-10-31 at 08:18 +0100, address@hidden wrote:
> Hi,
> 
> the jsr/return is only part ot the problem. We need to know the number of 
> levels where the catcher is and adjust the stack according to this number of 
> levels. In your sample the catch block is in the first finalizer block so the 
> level is 1.
> If there were other try{} finalize{} blocks in this finalizer and the 
> exception is thrown in one of the nested finalizers the level still has to be 
> 1 because the catcher is in the first finalizer.
> 
> If we assume that the return addresses are just on top of the stack base of 
> the current function (which should be because the stack should be empty on 
> entry of a finalize block) we should record the number of levels in the 
> ILException object and adjust the stack just before the ecxeption object is 
> pushed on the stack and the catch block is executed.
> 
> Maybe i missed something, but that's what came to my mind after thinking more 
> about the problem.

No, that should not be a problem.  Each finalizer is invoked
via a jsr and executes a ret_jsr on completion.   Each time 
a jsr is done exceptHeight gets incremented.  Each time the 
matching ret_jsr is done the exceptHeight is decremented.  
So exceptHeight should also match the number of finalizers 
currently running.

Its the throws that stuff things up.  A ret_jsr isn't
executed when a throw is done inside a finally.  God knows
what happens then - I haven't tested it.

One observation - the storing the jsr return address in a
local would fix the problem entirely.  My other solution 
wouldn't.  I don't know if introducing new locals that
don't match existing C# variables is a problem or not.
I can't see that is would be - but I don't know the code.