-
Bug
-
Resolution: Fixed
-
P3
-
1.0.3, 1.4.0
-
02
-
generic, x86
-
solaris_7, windows_nt
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2045943 | 1.4.0 | Neal Gafter | P3 | Closed | Fixed | beta3 |
Copied from the comments section of 4349534:
This problem showed up in J2ME (KVM) when
using a debugger that had set a breakpoint on the first line of a catch block.
Trying this on J2SE causes J2SE to crash as well.
Here's the source:
1
2
3 public class test {
4
5 public static void main(String [] args) {
6 try {
7 int jj = 4099; // change to jj = 0 and it works
8 foo();
9 } catch (Exception e) {
10 System.out.println(e); <-- brkpt here
11 }
12 }
13
14 public static void foo() throws Exception {
15 throw new Exception();
16 }
17 }
What happens is that after the KVM (or J2SE) sends the breakpoint event to the
debugger, the debugger tries to access the local variable 'e'. According to
the local variable table 'e' is valid from offset 8 in the method 'main'.
However, in looking at the code dump you can see that 'e' is not set until
the instruction at offset 8 is executed. 'e' should be valid starting at
offset 9. Depending on what value was stored in that local slot previously
the VM may or may not crash at this point. In the test program if you change
the 'jj' variable to '0' the VM determines that the variable 'e' is
null so it doesn't crash and it returns 'null' to the debugger as the value for
'e' (somewhat incorrect, but not fatal).
HEre's the relevant dump from javap:
Method void main(java.lang.String[])
0 iconst_0
1 istore_1
2 invokestatic #2 <Method void foo()>
5 goto 16
8 astore_1
9 getstatic #4 <Field java.io.PrintStream out>
12 aload_1
13 invokevirtual #5 <Method void println(java.lang.Object)>
16 return
Exception table:
from to target type
0 5 8 <Class java.lang.Exception>
Line numbers for method void main(java.lang.String[])
line 7: 0
line 8: 2
line 10: 8
line 12: 16
Local variables for method void main(java.lang.String[])
java.lang.String[] args pc=0, length=17, slot=0
int jj pc=2, length=3, slot=1
java.lang.Exception e pc=8, length=8, slot=1
bill.pittore@East 2001-08-01
This problem showed up in J2ME (KVM) when
using a debugger that had set a breakpoint on the first line of a catch block.
Trying this on J2SE causes J2SE to crash as well.
Here's the source:
1
2
3 public class test {
4
5 public static void main(String [] args) {
6 try {
7 int jj = 4099; // change to jj = 0 and it works
8 foo();
9 } catch (Exception e) {
10 System.out.println(e); <-- brkpt here
11 }
12 }
13
14 public static void foo() throws Exception {
15 throw new Exception();
16 }
17 }
What happens is that after the KVM (or J2SE) sends the breakpoint event to the
debugger, the debugger tries to access the local variable 'e'. According to
the local variable table 'e' is valid from offset 8 in the method 'main'.
However, in looking at the code dump you can see that 'e' is not set until
the instruction at offset 8 is executed. 'e' should be valid starting at
offset 9. Depending on what value was stored in that local slot previously
the VM may or may not crash at this point. In the test program if you change
the 'jj' variable to '0' the VM determines that the variable 'e' is
null so it doesn't crash and it returns 'null' to the debugger as the value for
'e' (somewhat incorrect, but not fatal).
HEre's the relevant dump from javap:
Method void main(java.lang.String[])
0 iconst_0
1 istore_1
2 invokestatic #2 <Method void foo()>
5 goto 16
8 astore_1
9 getstatic #4 <Field java.io.PrintStream out>
12 aload_1
13 invokevirtual #5 <Method void println(java.lang.Object)>
16 return
Exception table:
from to target type
0 5 8 <Class java.lang.Exception>
Line numbers for method void main(java.lang.String[])
line 7: 0
line 8: 2
line 10: 8
line 12: 16
Local variables for method void main(java.lang.String[])
java.lang.String[] args pc=0, length=17, slot=0
int jj pc=2, length=3, slot=1
java.lang.Exception e pc=8, length=8, slot=1
bill.pittore@East 2001-08-01
- backported by
-
JDK-2045943 REGRESSION: bad local variable table for exception parameter of catch block
- Closed
- relates to
-
JDK-4349534 regression - bad LocalVariableTable attribute when no initialization needed
- Resolved