dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: ktreichel
Subject: Re: [Pnet-developers] Re: [DotGNU] Bug in Pnet
Date: Tue, 31 Oct 2006 08:55:49 +0100

oops, i didn't mean finalizer but finally block ;)

> -----Ursprüngliche Nachricht-----
> Von: Russell Stuart <address@hidden>
> Gesendet: 31.10.06 08:34:58
> An: address@hidden
> Betreff: Re: [Pnet-developers] Re: [DotGNU] Bug in Pnet


> 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.
> 
> _______________________________________________
> Pnet-developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/pnet-developers


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066



reply via email to

[Prev in Thread] Current Thread [Next in Thread]