==>If you compile the following program:
==>
==>public class TestClass
==>{
==> public void MyFunc( int i )
==> {
==> int k = 3;
==> double d = 2.2d;
==> }
==> public static void main( String args[] )
==> {
==> TestClass mc = new TestClass();
==> mc.MyFunc( 5 );
==> }
==>}
==>
==>-g with the Sybase Java compiler then use:
==>
==>
==>jdb TestClass
==>stop in TestClass.MyFunc
==>run
==>
==>the VM will crash with:
==>
==>java.lang.Exception: java.lang.InternalError: Invalid Arguments in Local
==>VariableTable
==> at sun.tools.debug.RemoteAgent.getReply(RemoteAgent.java:456)
==> at sun.tools.debug.RemoteAgent.dumpStack(RemoteAgent.java:583)
==> at sun.tools.debug.RemoteThread.getStack(RemoteThread.java:278)
==> at sun.tools.debug.RemoteThread.dumpStack(RemoteThread.java:129)
==> at sun.tools.ttydebug.TTY.breakpointEvent(TTY.java:80)
==> at sun.tools.debug.AgentIn.run(AgentIn.java:62)
==> at java.lang.Thread.run(Thread.java:468)
==>
==>The classfile we are creating is legal. I modified our classfile until the
==> only difference between our classfile and the one produced
==>by your javac compiler is that our local variable table does not have the
==>local variables ordered by index.
==>That is, the first one listed is a local, and the last one listed is "this"
==> at index 0.
==>
==>This problem does not exist with other JDKs, although I'm not sure which
==>Beta of JDK1.2 introduced it.
==>
==>Here is a (small) classfile from our compiler which will reproduce the
==>problem.
==>
==>(See attached file: TestClass.class)
==>
==>I would appreciate a fix for this in the next beta of JDK1.4. We do not
==>want to have to ship our compiler with the workaround of
==>always sorting the local variable table.
==>
==>I have submitted a bug report for this, but of course I could include the
==>classfile there.
==>
==>public class TestClass
==>{
==> public void MyFunc( int i )
==> {
==> int k = 3;
==> double d = 2.2d;
==> }
==> public static void main( String args[] )
==> {
==> TestClass mc = new TestClass();
==> mc.MyFunc( 5 );
==> }
==>}
==>
==>-g with the Sybase Java compiler then use:
==>
==>
==>jdb TestClass
==>stop in TestClass.MyFunc
==>run
==>
==>the VM will crash with:
==>
==>java.lang.Exception: java.lang.InternalError: Invalid Arguments in Local
==>VariableTable
==> at sun.tools.debug.RemoteAgent.getReply(RemoteAgent.java:456)
==> at sun.tools.debug.RemoteAgent.dumpStack(RemoteAgent.java:583)
==> at sun.tools.debug.RemoteThread.getStack(RemoteThread.java:278)
==> at sun.tools.debug.RemoteThread.dumpStack(RemoteThread.java:129)
==> at sun.tools.ttydebug.TTY.breakpointEvent(TTY.java:80)
==> at sun.tools.debug.AgentIn.run(AgentIn.java:62)
==> at java.lang.Thread.run(Thread.java:468)
==>
==>The classfile we are creating is legal. I modified our classfile until the
==> only difference between our classfile and the one produced
==>by your javac compiler is that our local variable table does not have the
==>local variables ordered by index.
==>That is, the first one listed is a local, and the last one listed is "this"
==> at index 0.
==>
==>This problem does not exist with other JDKs, although I'm not sure which
==>Beta of JDK1.2 introduced it.
==>
==>Here is a (small) classfile from our compiler which will reproduce the
==>problem.
==>
==>(See attached file: TestClass.class)
==>
==>I would appreciate a fix for this in the next beta of JDK1.4. We do not
==>want to have to ship our compiler with the workaround of
==>always sorting the local variable table.
==>
==>I have submitted a bug report for this, but of course I could include the
==>classfile there.