dotgnu-pnet
[Top][All Lists]
Advanced

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

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


From: Russell Stuart
Subject: [Pnet-developers] [Fwd: Re: [DotGNU] Bug in Pnet]
Date: Mon, 30 Oct 2006 19:23:18 +1000

On Mon, 2006-10-30 at 09:09 +0100, address@hidden wrote:
> Hi Russel,
> 
> as much as i can see is that there is a segfault with this program with jit 
> and cvm.
> 
> With jit  the problem is on the return from the finally handler.
> 
> Looks like the stack is messed up there somewhere.
> 
> Btw. I've checked on cygwin.

Yes, the stack is being corrupted.  The exact mechanism is:

  1.  The finally{} clause starts executing.  It generates
      these two CVM instructions:

         start_finally
         jsr  finally_code

      It is the second instruction that is of interest.  It pushes
      the return address for the jsr onto the stack.

  2.  The target of the jsr is the try{throw;}catch{}.  
      The throw is executed.  Here is a comment from within
      cvm_except.c: "The stack is then reset to the same as 
      the current method's exception frame height."  The
      one thing thrown away in this case is the return 
      address of the jsr.  This is the bug.

  3.  The catch() executes as it should.

  4.  The finally code now executes the CVM instruction
      ret_jsr.  But the stack is empty ...

It has taken me this long to figure that out.  The tricky
part is fixing it.  The first thing that comes to mind
is getting jsr/ret_jsr to adjust the exception frame 
height, but that is ugly because it assumes that jsr is 
only used for finally.  I think that is true.  Anyone
get a better idea?

Anyway, I will fix the interpreter.  I don't even want
to think about fixing the jit.  It is interesting the
bug got copied over to it though.




reply via email to

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