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: Russell Stuart
Subject: Re: [Pnet-developers] Re: [DotGNU] Bug in Pnet
Date: Mon, 30 Oct 2006 19:41:18 +1000

On Mon, 2006-10-30 at 18:57 +1000, Russell Stuart wrote:
> 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?

Replying to myself ... that does look like a reasonable
way to fix it.  Unfortunately there is another bug, and
how to fix it is not so obvious.

VMCASE(COP_PREFIX_ENTER_TRY) sets thread->exceptHeight.  
The reason is described in comment above viz: 'It sets 
the "base height" of the stack so that <i>throw</i> 
instructions know where to unwind the stack to when an 
exception is thrown.'

Fine.  But nowhere is thread->exceptHeight is restored
when the try{} block exits.  So I expect that something
like this:

  try {
     // thread->exceptHeight = stoptop in COP_PREFIX_ENTER_TRY
     some code that alters the stack height;
     try {
       // thread->exceptHeight = stoptop in COP_PREFIX_ENTER_TRY
     }
     catch (Exception e) {}
     // thread->exceptHeight hasn't been restored at this point
     throw new Exception();
  }
  catch (Exception e) {
    // e at this point contains an invalid stack.
  }

My problem is as far as I can tell, there is no code
executed when a try{}catch(){} block exits, so its
not possible to fix the bug without introducing
another CVM opcode that is executed at the end of
a try{}catch(){} block.

I'll just fix the original problem for now.




reply via email to

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