Community
Participate
Working Groups
Created attachment 246382 [details] Screen shot showing blank line for first array element - Compile and debug the following C program. I was using cygwin. #include <stdio.h> #include <stdlib.h> int main(void) { int a[10] = {1,2,3,4,5,6,7,8,9,10}; int b[10] = {1,2,3,4,5,6,7,8,9,10}; int c[10] = {1,2,3,4,5,6,7,8,9,10}; puts("!!!Hello World!!!"); /* prints !!!Hello World!!! */ return EXIT_SUCCESS; } - step to after the arrays (step to puts). - Now you have to do a very specific sequence in the variables view. Be sure the variables view is short enough that not all elements of an array can be shown at one time. -- Click on the triangle next to 'a' to show a's elements. -- Scroll and open 'b'. -- Scroll and open 'c' -- Click the collapse all button (-) -- Click on the triangle next to 'c' to open it. Notice the line for c[0] is blank. Screen shot attached showing this. SWT: 3.103.1.v20140806-1303 Eclipse: Luna
I don't see this on my Linux box. I wonder if this could be a platform issue or if it is specific to CDT (DSF). Chris, what happens when you select the blank entry? Does it show anything in the detail pane below (where it normally shows the variable in different format such as octal and binary)? Can you reproduce the same problem with a java program?
The details pane remains blank after clicking on the blank line. It does happen when debugging a similar java program. Interesting. package aaa; public class Aaa { Aaa() { int a[] = {1,2,3,4,5,6,7,8,9,10}; int b[] = {1,2,3,4,5,6,7,8,9,10}; int c[] = {1,2,3,4,5,6,7,8,9,10}; System.out.println("!!!Hello World!!!"); /* prints !!!Hello World!!! */ } public static void main(String args[]) { new Aaa(); } }
This does not occur in C or java on Ubuntu Linux under VirtualBox.
(In reply to Chris Genly from comment #2) > It does happen when debugging a similar java program. Interesting. Since it happens with both JDT and CDT, it looks like a platform issue. I'm sending this to SWT. > This does not occur in C or java on Ubuntu Linux under VirtualBox. Also sounds like it is Windows-specific.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
Wow! This is an old bug. I just tried the example and the problem still exists. I would still like it fixed. Windows 10 cygwin64
Created attachment 280836 [details] Screenshot Can't reproduce macOS,Eclipse 2019-12
(In reply to Chris Genly from comment #0) > - Now you have to do a very specific sequence in the variables view. Be sure > the variables view is short enough that not all elements of an array can be > shown at one time. > -- Click on the triangle next to 'a' to show a's elements. > -- Scroll and open 'b'. > -- Scroll and open 'c' > -- Click the collapse all button (-) > -- Click on the triangle next to 'c' to open it. Indeed a very special sequence. A crucial point is to not scroll after before collapsing. Can reproduce the Java variant on Windows 7 with recent Eclipse version.
This is an awful bug! Was hard to find the point where it is failing and much harder to find the reason it is failing. It's not even entirely clear to what component this bug should be assigned. Debug, UI/JFace, SWT all do there part to enable this bug. I assign it to UI because the easiest variants to fix it is there. This bug will probably not happen outside this very specific environment. It will probably only happen in Variables view and maybe some other debug related views. It is platform dependent but not really a SWT bug. It should only happens after collapse all. You must expand more than one tree item and have the children of the second one never all visible. Variable view set the items asynchronous which does not seem to be optimal supported by AbstractTreeViewer nor Table. My proposed fix is after all incredible simple. Collapse all at the moment collapse all 'root' elements from the first to the last. Fix is to do it in reverse. If someone is interested here the longer story why this fix works and where the actual problem is. Variables view use a virtual lazy tree viewer and, as already mentioned, when a tree item is requested/to be shown the data is collected asynchronous. From SWT point of view a virtual tree initialized on demand. There exist only the items which are or were visible and empty items for all direct children of such an initialized item. When an item becomes visible SWT will fire an SetData event for the content provider to initialize the item. AbstractTreeViewer forward this request to Variables view which schedules an asynchronous update for this. So if SetData returns the Tree assumes this item is initialized and set the cached flag but the data is not yet set since the update is pending. The later item update is passed through TreeViewer and identified with parent item and child index. This is one key component for the bug. Most important part from the previous paragraph: when initializing a newly shown item SWT assumes it is done immediately but Variables view does it asynchronous and the actual update is done through TreeViewer based on parent item and child index. Now what is done on collapse all: it will iterate through the 'root' items (first to last), collapse them and remove all child items (prune) but one dummy to keep the expand/collapse button. The code will try to reuse the first existing not yet initialized child item as dummy. And now for the point where this bug can actually manifests. As already mentioned you must open more than one. Collapse all will start to collapse the first array. TreeViewer will force an update/repaint of the tree area. Since the first array is collapsed this will move up the elements of the second array which are not all yet materialized and require Tree to request the data for this virtual items. Variables view will schedule an update but not yet set the item data. Before this update can happen the second array gets collapsed and pruned it. It need a dummy item to remain the expand/collapse button and will reuse the first "virtual" item which is the first item without data. Now we have a dummy item where AbstractTreeViewer assumes it is virtual because it has no data but Tree assumes it is not virtual because it already fired SetData. The actual content update from Variables view will be executed and try to set the item based on index which is now wrong since all but one item where removed. The reason why the simple fix works in this case. If we collapse from the last to the first item no virtual items are brought into view while collapsing. (at least not long enough to initialize them)
New Gerrit change created: https://git.eclipse.org/r/153853
(In reply to Eclipse Genie from comment #10) > New Gerrit change created: https://git.eclipse.org/r/153853 > are brought into view while collapsing If we turn redraw of during the collapse of the tree does this bug still occur?
(In reply to Lars Vogel from comment #11) > (In reply to Eclipse Genie from comment #10) > > New Gerrit change created: https://git.eclipse.org/r/153853 > > > are brought into view while collapsing > > If we turn redraw of during the collapse of the tree does this bug still > occur? This bug can be fixed in quite many ways. Some complex, some simple. And while I indeed looked for a disable redraw or similar method in AbstractTreeViewer I'm still mad I forgot about the underlying widget. All that debugging made me dizzy. :D So yes, disabling redraw is one of the possible simple fixes. I'll abandon my change and see how bug 553788 proceed. If we cannot disable redraw for any reason I still can do my reverse collapsing. Btw: the first patch I had in mind would had changed the 'prune children add dummy item' logic to not reuse an existing but always create a new item. That also worked.
Fixed via bug 553788.
