-
Bug
-
Resolution: Fixed
-
P3
-
6
-
generic
-
generic
http://www.netbeans.org/issues/show_bug.cgi?id=151832
In the attached class, step through pickFrom() method in debugger.
It happens several times in the for cycle that the current program counter is displayed on line 29, which is "return serviceInfo;" But the execution does not return! This is misleading.
Looking into the class file makes it clear:
42: aload_3
43: areturn
44: goto 12
47: aconst_null
48: areturn
LineNumberTable:
line 26: 0
line 28: 31
line 29: 42
line 31: 47
From this it's apparent that line 29 refers to
42: aload_3
43: areturn
which is O.K., but also to
44: goto 12
which is wrong IMHO.
This could be fixed by adding
line 30: 44
into the LineNumberTable, for instance.
I'm increasing priority, because this bug is a source of confusion for users and we keep to get bug reports for wrong stepping behavior.
See http://www.netbeans.org/issues/show_bug.cgi?id=168365 and http://www.netbeans.org/issues/show_bug.cgi?id=171169
See the attached WrongLine.zip file.
Submit breakpoint to line 32 and debug. // if (!statusList.contains(us)) {
When the condition is false (during the second pass), program counter unexpectedly goes to line 37. (Line 38 is missing in LineNumberTable according to WrongLine1.bytecodes)
Uncomment the two lines (33, 34) and debug again. Now debugger steps correctly and line 38 is suddenly present in LineNumberTable according to WrongLine2.bytecodes.
Also see http://www.netbeans.org/issues/show_bug.cgi?id=171169 and the attachment Bugs.zip, where debugger steps into "catch" block even though no exception was thrown.
These all looks like similar issues in creation of LineNumberTable.
In the attached class, step through pickFrom() method in debugger.
It happens several times in the for cycle that the current program counter is displayed on line 29, which is "return serviceInfo;" But the execution does not return! This is misleading.
Looking into the class file makes it clear:
42: aload_3
43: areturn
44: goto 12
47: aconst_null
48: areturn
LineNumberTable:
line 26: 0
line 28: 31
line 29: 42
line 31: 47
From this it's apparent that line 29 refers to
42: aload_3
43: areturn
which is O.K., but also to
44: goto 12
which is wrong IMHO.
This could be fixed by adding
line 30: 44
into the LineNumberTable, for instance.
I'm increasing priority, because this bug is a source of confusion for users and we keep to get bug reports for wrong stepping behavior.
See http://www.netbeans.org/issues/show_bug.cgi?id=168365 and http://www.netbeans.org/issues/show_bug.cgi?id=171169
See the attached WrongLine.zip file.
Submit breakpoint to line 32 and debug. // if (!statusList.contains(us)) {
When the condition is false (during the second pass), program counter unexpectedly goes to line 37. (Line 38 is missing in LineNumberTable according to WrongLine1.bytecodes)
Uncomment the two lines (33, 34) and debug again. Now debugger steps correctly and line 38 is suddenly present in LineNumberTable according to WrongLine2.bytecodes.
Also see http://www.netbeans.org/issues/show_bug.cgi?id=171169 and the attachment Bugs.zip, where debugger steps into "catch" block even though no exception was thrown.
These all looks like similar issues in creation of LineNumberTable.
- relates to
-
JDK-4026902 add support for line numbers from more than one file
-
- Closed
-
-
JDK-4843674 RFE: need source line number info for native/abstract methods in class file
-
- Closed
-