[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pnet-developers] Re: [DotGNU] Bug in Pnet
From: |
Russell Stuart |
Subject: |
[Pnet-developers] Re: [DotGNU] Bug in Pnet |
Date: |
Mon, 30 Oct 2006 18:57:06 +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.