Bug in Pnet

Hi Russel,

looks like it's not really the exception height where the
problem is but the number of nested blocks called through
jsr where the catcher is.

So adjusting the frameheight on jsr/ret_jsr sounds
reasonable for me because it should do the same for other
blocks called through jsr too.

Cheers,

Klaus
> -----Ursprüngliche Nachricht-----
> Von: Russell Stuart <rstuartlubemobile.com.au>
> Gesendet: 30.10.06 10:41:48
> An: ktreichelweb.de
> CC: pnet-developersdotgnu.org
> Betreff: Re: [Pnet-developers] Re: [DotGNU] Bug in Pnet


> 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.
> 
> 


____________________________________________________________
___________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und
kostenlos.
Gleich testen! h
ttp://www.pc-sicherheit.web.de/freescan/?mc=022222

_______________________________________________
Pnet-developers mailing list
Pnet-developersdotgnu.org
ht
tp://dotgnu.org/mailman/listinfo/pnet-developers

Hi all,

As far as JIT is concerned perhaps every finally block that
may throw
has to define its own setjmp context.

Regards,
Aleksey

2006/10/30, ktreichelweb.de <ktreichelweb.de>:
> Hi Russel,
>
> looks like it's not really the exception height where
the problem is but the number of nested blocks called
through jsr where the catcher is.
>
> So adjusting the frameheight on jsr/ret_jsr sounds
reasonable for me because it should do the same for other
blocks called through jsr too.
>
> Cheers,
>
> Klaus
> > -----Ursprüngliche Nachricht-----
> > Von: Russell Stuart <rstuartlubemobile.com.au>
> > Gesendet: 30.10.06 10:41:48
> > An: ktreichelweb.de
> > CC: pnet-developersdotgnu.org
> > Betreff: Re: [Pnet-developers] Re: [DotGNU] Bug in
Pnet
>
>
> > 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.
> >
> >
>
>
>
____________________________________________________________
___________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort,
online und kostenlos.
> Gleich testen! h
ttp://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> _______________________________________________
> Pnet-developers mailing list
> Pnet-developersdotgnu.org
> ht
tp://dotgnu.org/mailman/listinfo/pnet-developers
>
_______________________________________________
Pnet-developers mailing list
Pnet-developersdotgnu.org
ht
tp://dotgnu.org/mailman/listinfo/pnet-developers

Hi all,

As far as JIT is concerned perhaps every finally block that
may throw
has to define its own setjmp context.

Regards,
Aleksey

2006/10/30, ktreichelweb.de <ktreichelweb.de>:
> Hi Russel,
>
> looks like it's not really the exception height where
the problem is but the number of nested blocks called
through jsr where the catcher is.
>
> So adjusting the frameheight on jsr/ret_jsr sounds
reasonable for me because it should do the same for other
blocks called through jsr too.
>
> Cheers,
>
> Klaus
> > -----Ursprüngliche Nachricht-----
> > Von: Russell Stuart <rstuartlubemobile.com.au>
> > Gesendet: 30.10.06 10:41:48
> > An: ktreichelweb.de
> > CC: pnet-developersdotgnu.org
> > Betreff: Re: [Pnet-developers] Re: [DotGNU] Bug in
Pnet
>
>
> > 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.
> >
> >
>
>
>
____________________________________________________________
___________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort,
online und kostenlos.
> Gleich testen! h
ttp://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> _______________________________________________
> Pnet-developers mailing list
> Pnet-developersdotgnu.org
> ht
tp://dotgnu.org/mailman/listinfo/pnet-developers
>
_______________________________________________
Pnet-developers mailing list
Pnet-developersdotgnu.org
ht
tp://dotgnu.org/mailman/listinfo/pnet-developers

Fixes committed to CVS.

After a nights sleep the other problem I realised the
other problem I talked about doesn't exist.

On Mon, 2006-10-30 at 16:13 +0100, ktreichelweb.de
wrote:
> Hi Russel,
> 
> looks like it's not really the exception height where
the problem is but the number of nested blocks called
through jsr where the catcher is.
> 
> So adjusting the frameheight on jsr/ret_jsr sounds
reasonable for me because it should do the same for other
blocks called through jsr too.

jsr is only used for finally blocks, as far as I
can tell.


_______________________________________________
Pnet-developers mailing list
Pnet-developersdotgnu.org
ht
tp://dotgnu.org/mailman/listinfo/pnet-developers

On Tue, 2006-10-31 at 07:58 +1000, Russell Stuart wrote:
> Fixes committed to CVS.

After thinking about it, the fix I doesn't really
solve the problem.  It only goes 1/2 way.  The 
demonstration code I posted now works, and I can
now continue development without ilrun getting
segmentation violations.

However, the stack record by the "throw" will be
wrong.  I presume whoever is looking at the stack
recorded by the exception will not be expecting 
the jsr return address to be in there.  Currently
two fixes come to mind.  I don't know the code
well enough to say which is better.

1.  Create a local for the finally, and store the
    return address in there at the top of the finally
    block.

2.  Create a second version of the exceptHeight variable.
    One version is the stack height at entry to the 
    function - just as was done before, the other is 
    adjusted by jsr - as is done now.   The first is 
    used when the stack is recorded.  The second is
    what throw truncates the stack to.

No.2 is probably easier for me to implement.  Any other
suggestions?

_______________________________________________
Pnet-developers mailing list
Pnet-developersdotgnu.org
ht
tp://dotgnu.org/mailman/listinfo/pnet-developers