Community
Participate
Working Groups
3.3 M3 VM: IBM 1.5.0 SR3 - stepping through some layout code, I stepped into Composite.computeSize(int,int,boolean) (the receiver was actually a ui.forms LayoutComposite) - stepped past where size was declared (as: Point size;) - stepped past the if block (it went through the else block which has: size = minimumSize (wHint, hHint, changed);) - size did not show up in the Variables view - stepped past where trim was declared and assigned - trim showed up OK, but still no size
Appears to be an issue with the IBM 1.5 VMs. Does not happen with Sun VMs or IBM 1.4.x VMs.
Do you know under which conditions it does this? Is it just for vars declared before they're assigned?
Can reproduce with a simple case: import java.awt.Point; import java.awt.Rectangle; public class Locals { public static void main(String[] args) { Locals locals = new Locals(); locals.simple(true); } public void simple(boolean bool) { Object o; if (bool) { o = new Point(1,2); } else { o = new Point(3,4); } System.err.println(o); } } javap shows the variable table as: public void simple(boolean); LocalVariableTable: Start Length Slot Name Signature 0 35 0 this LLocals; 0 35 1 bool Z 14 3 2 o Ljava/lang/Object; 27 8 2 o Ljava/lang/Object; When debugging with IBM 1.4.x VM, the variable 'o' (second occurrence) appears with the correct start index, but a length of 40. When debugging with IBM 1.5.x VM, the variable appears with correct start index, but a length of 0 (and thus, does not appear visible, as according to the JDWP spec). In both cases, the length attributes are incorrect from the IBM VM.
I'm not sure what all the cases are - but it definitely appears to be a bug somewhere on the VM side, we're just doing a readInt() from a DataInputStream and getting '40' back. Marking as Won't fix. Will file a bug with VM team.
Should be a readme
CC'ing VM team member so they are aware of the issue.
Thanks for the info. Graham, if there's a later VM, I'd be happy to check this case.
I'll check into it. In the 2.3 VM (Java5 for most customers), we introduced some code to verify and shorten local variable ranges, because the Sun JDK compilers often produce completely invalid local variable tables, which were causing the VM to crash. It's possible there's an error in this code.
The problem is indeed the local variable shortening. Without going into too much detail, the issue is that there is a branch from outside the visible range of the second "o" variable to within it's range. As a result, we shorten the end of the visible range to the branch target, which in this case results in the visible range being empty.
FYI, I've opened: https://bugs.ottawa.ibm.com/show_bug.cgi?id=123732 to track this from our side.
Now covered by CMVC 121765. Will be addressed for 150 SR6.
