Community
Participate
Working Groups
1. Debug the following program to a breakpoint on the first line of foo(). Variables view looks like: this = VariableTest 2. Perform a step over. Variables view looks like: x = 1 this = VariableTest 3. Perform a step over. Variables view looks like: this = VariableTest y = 2 x = 1 The ordering of existing variables shouldn't change when new variables are added. public class VariableTest { public static void main(String[] args) { new VariableTest().foo(); } private void foo() { int x= 1; // BREAKPOINT HERE int y= 2; System.out.println("Grah"); } }
A side-effect of the reordering is that expanded variables are collapsed.
This appears to be a UI/SWT problem. Reassigning to UI. Information which may be useful for debugging this problem: 1. Launch a TARGET Eclipse. 2. In the TARGET, create the test case above and launch it in debug mode such that it suspends at the breakpoint. 3. In the HOST, put a breakpoint in AbstractTreeViewer#internalRefresh(Widget, Object, boolean) on line 842, which reads: Item[] children= getChildren(widget); 4. In the TARGET, click "Step Over." 5. The HOST will suspend at the breakpoint a couple times with many stack frames from LaunchViewer. Resume until it suspends with calls from VariablesViewer on the stack (for me, I have to resume twice). 6. Expand "widget" in the variables view and take a look at its tree items. item[0] has a JDIThisVariable. item[1] has a JDILocalVariable. This is the correct ordering for display. 7. Step over the call to getChildren(widget); and examine the collection of items in the children array. children[0] has a JDILocalVariable. children[1] has a JDIThisVariable. It seems that the call to getChildren(), which ultimately ends up in Tree.getChildren() is returning the children in reverse order in this case.
getChildren(widget) gets the items out of the widget, so this must be after the problem occurs. Need to look at call to getSortedChildren(element).
Jared, if you have time can you look at the call to getSortedChildren. I'd be very surprised if there is a bug in the viewers here since we just sort the collection using the java.util classes and then process the items in order. I suspect a problem with your sorter. Also, what notifications do you get from JDI for the appearance of a new variable? If you get told about individual variables coming into scope, it would be better to use add rather than refresh.
I debugged the problem to the current test case by stepping through the getSortedItems() call that results from the updateChildren() call just above the breakpoint. At the location I indicated, we've already got the items from the content provider, run them through any filters, and the sorter (there actually isn't one). As explained in the test case, the items are in the correct order in the Tree. I actually debugged this down into the Tree implementation and it appears to be a GTK bug - I don't know enough to say if it's our GTK natives or GTK itself. From org.eclipse.swt.widgets.Tree (my comments inserted): TreeItem [] getItems (int node) { ... // At this point in the method, this.items[] has the items in the correct order. Items = new TreeItem [Count]; Count = 0; Callback GtkCTreeGetItems = new Callback (this, "GtkCTreeGetItems", 3); int address1 = GtkCTreeGetItems.getAddress (); OS.gtk_ctree_post_recursive_to_depth (handle, node, depth, address1, node); GtkCTreeGetItems.dispose (); // At this point, Items contains the TreeItems from this.items[] but in reverse order. TreeItem [] result = Items; Items = null; return result; } We've tested on Win2K and Linux-Motif and verified that this problem DOESN'T exist on those platforms. Recommend moving to SWT.
Is the bug that you are seeing that the tree does not return the items in the order they show up in the widget? If so, then this is a serious problem, but may not be something we can fix. Boris, please investigate.
That's correct. The widget shows the items listed in the order that our content provider game them: ThisVariable LocalVariable but the Tree is returning them in the reverse order in this case.
Fixed. This was not related to the order of returned items, but rather insertion of new items was bogus (see Tree.GtkCTreeFindSibling()).
*** Bug 17570 has been marked as a duplicate of this bug. ***
