Community
Participate
Working Groups
Using I20070323-1616, and running the SWT/JFace snippet from bug 172640 after applying the latest JFace patch from that bug, I got this: Gtk-ERROR **: file gtktreestore.c: line 579 (gtk_tree_store_get_path): assertion failed: (G_NODE (iter->user_data)->parent != NULL) aborting... JVMDG217: Dump Handler is Processing Signal 6 - Please Wait. JVMDG303: JVM Requesting Java core file JVMDG304: Java core file written to /home/bokowski/TheWorkspace/snip/javacore.20070416.135336.19339.txt JVMDG215: Dump Handler has Processed Error Signal 6.
Created attachment 63931 [details] thread dump
To reproduce, run the snippet, expand all nodes in the tree, scroll down, and click on "Sort" multiple times.
Steps to reproduce: 1. Run the snippet 2. Expand all nodes top-down 3. Scroll all the way to the last item 4. Click on Sort 5. Click on Sort -> Crash
I cannot reproduce this without jface code. If we can find an SWT only test case it would really help us isolate the bug. Seems that GTK model is changing and the view is not getting updated properly. Also I haven't crashed on GTK 2.10.4 (but Bogdan has).
The jface code is calling setItemCount on the item's parent within a SetData call back. The result of this is that while processing the callback, the item is destroyed causing the failure. Bug 158052 is similar. A similar SWT only test case that does the same thing and also crashes: public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); final Tree tree = new Tree(shell, SWT.VIRTUAL); tree.setItemCount(2); tree.setSelection(tree.getItem(1)); tree.clearAll(true); tree.addListener(SWT.SetData, new Listener() { public void handleEvent(Event event) { TreeItem item = (TreeItem) event.item; if (item.getParentItem() == null) { item.setText("item - " + event.index); } else { TreeItem parent = item.getParentItem(); int parentIndex = tree.indexOf(parent); item.setText("child " + parentIndex + "/" + event.index); } if (event.index == 1) { Thread.dumpStack(); tree.setItemCount(1); } } }); shell.setSize(250, 150); tree.setBounds(10, 10, 200, 100); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); }
This is no longer blocking bug 172640, but it would be good if the crash could be prevented by detecting this case and throwing an exception.
This bug is still reproducible for me. Assigning to Ian.
*** Bug 218877 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/79294
Hi, due to some other matters I have not been able to follow up with the bug. I will reassign this back to anyone who is interested in working on this.
We probably hit this one in our application based on 4.10. Strange enough, there were no JVM dump file, but Eclipse disappears without a comment and the only trace I've found was the line printed to standard error: ** Gtk:ERROR:gtktreestore.c:596:gtk_tree_store_get_path: assertion failed: (G_NODE (iter->user_data)->parent != NULL) The snippet from comment 5 crashes perfectly with the current SWT head, BUT I see the JVM dump and the GTK errors are *different*: (SWT:25478): Gtk-CRITICAL **: gtk_cell_area_apply_attributes: assertion 'iter != NULL' failed (SWT:25478): Gtk-CRITICAL **: gtk_tree_model_get_path: assertion 'iter != NULL' failed (SWT:25478): Gtk-CRITICAL **: gtk_tree_model_get_path: assertion 'iter != NULL' failed (SWT:25478): Gtk-CRITICAL **: gtk_tree_view_row_expanded: assertion 'path != NULL' failed # # A fatal error has been detected by the Java Runtime Environment: [...] The original example attachment 63930 [details] from bug 172640 does NOT crash SWT today. We will investigate.
Bug 39443 (fixed) is similar but example doesn't crash SWT from today.
I used to experience this bug pretty frequently, IIRC it was more reproducible when debugging TreeItem code (I think it was TreeItem.setImage()) but I don't have any conclusive proof.
(In reply to Eric Williams from comment #13) > I used to experience this bug pretty frequently, IIRC it was more > reproducible when debugging TreeItem code (I think it was > TreeItem.setImage()) but I don't have any conclusive proof. Was SWT crashing or only some GTK errors were reported?
(In reply to Andrey Loskutov from comment #14) > (In reply to Eric Williams from comment #13) > > I used to experience this bug pretty frequently, IIRC it was more > > reproducible when debugging TreeItem code (I think it was > > TreeItem.setImage()) but I don't have any conclusive proof. > > Was SWT crashing or only some GTK errors were reported? SWT was crashing without an hs_err*.log file and when I tried doing it in a child Eclipse the same assertions as here were reported. IIRC this was in 2015 so it would have been Mars/Neon times. And again, I didn't find a conclusive way to reproduce it, but I was working on TreeItem bugs at the time and it seemed to crash a lot when debugging that code.
We are closer now to reproduce it in our software. It must be a virtual tree. The tree must enter org.eclipse.swt.widgets.Tree.setItemCount(long, int) twice with parentIter == 0 and the second call must have count == 0. Means, while Tree.setItemCount call we get a callback from GTK which is dispatched to the clients which again call Tree.setItemCount on the *same* tree. This most likely invalidates iterator and as soon as the inner Tree.setItemCount call is done, the outer one crashes VM. I'm working on creating a standalone reproducer.
So far no luck with the SWT reproduction snippet; I'm unable to reproduce this sequence: at org.eclipse.swt.widgets.Tree.checkData(Tree.java:331) at org.eclipse.swt.widgets.Tree.cellDataProc(Tree.java:264) at org.eclipse.swt.widgets.Display.cellDataProc(Display.java:884) at org.eclipse.swt.internal.gtk.GTK._gtk_tree_store_remove(Native Method) at org.eclipse.swt.internal.gtk.GTK.gtk_tree_store_remove(GTK.java:7283) at org.eclipse.swt.widgets.Tree.destroyItem(Tree.java:1123) The GTK+ call just doesn't cause a Display.cellDataProc(). Eric any idea why removing an item in the GTK+ tree model would cause Dislay.cellDataProc() in the same call? I tried with different selections in the tree, scrollbars and so on. But the Display.cellDataProc calls come only after the Tree.destroyItem() code is fully through.
(In reply to Simeon Andreev from comment #17) > So far no luck with the SWT reproduction snippet; I'm unable to reproduce > this sequence: > > at org.eclipse.swt.widgets.Tree.checkData(Tree.java:331) > at org.eclipse.swt.widgets.Tree.cellDataProc(Tree.java:264) > at org.eclipse.swt.widgets.Display.cellDataProc(Display.java:884) > at org.eclipse.swt.internal.gtk.GTK._gtk_tree_store_remove(Native Method) > at org.eclipse.swt.internal.gtk.GTK.gtk_tree_store_remove(GTK.java:7283) > at org.eclipse.swt.widgets.Tree.destroyItem(Tree.java:1123) > > The GTK+ call just doesn't cause a Display.cellDataProc(). Eric any idea why > removing an item in the GTK+ tree model would cause Dislay.cellDataProc() in > the same call? I tried with different selections in the tree, scrollbars and > so on. But the Display.cellDataProc calls come only after the > Tree.destroyItem() code is fully through. CellDataProc is callback that only gets registered when the tree model changes, i.e. the content of the tree. The GTK docs about this callback are here: https://developer.gnome.org/gtk3/stable/GtkTreeViewColumn.html#GtkTreeCellDataFunc You can see where we enable it by doing a call hierarchy on gtk_tree_view_column_set_cell_data_func().
Well, after trying to write a JFace snippet and failing, I did notice that we have a TreeViewer.refresh() on the stack (in fact at the beginning of the stack). This refresh calls TreeItem.clearAll() on the tree input object. After playing around with calling Tree.clearAll() and TreeItem.clearAll(), here is a snippet which (at least on my workstation) reproduces the crash reported here: public class Bug182598_GTK_crash_recursive_set_item_count { // If we want to have a Java dump on crash, we need to set a different number of tree items on SWT.SetData callback. private static final boolean CRASH_WITH_DUMP = false; public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setSize(300, 200); shell.setLayout(new FillLayout()); final Tree tree = new Tree(shell, SWT.VIRTUAL); tree.addListener(SWT.SetData, new Listener() { @Override public void handleEvent(Event event) { int itemCount = CRASH_WITH_DUMP ? 0 : 1; tree.setItemCount(itemCount); } }); int N = 7; for (int i = 0; i < N; ++i) { TreeItem item = new TreeItem(tree, SWT.NONE); int c = i + 1; item.setText("item " + c); if (i >= 5) { item.setText("very long long long long long long item " + c); } item.setData("something " + c); tree.setSelection(item); } Button button = new Button(shell, SWT.NONE); button.setText("Tree.clearAll()"); button.addSelectionListener(new SelectionListener() { @Override public void widgetSelected(SelectionEvent e) { tree.clearAll(true); } @Override public void widgetDefaultSelected(SelectionEvent e) { } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); } } Result (all on standard error): (SWT:10595): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar ** Gtk:ERROR:gtktreestore.c:596:gtk_tree_store_get_path: assertion failed: (G_NODE (iter->user_data)->parent != NULL) Note that the display size and number of items in the tree and the text of the items seems to be magical; changing those changes the nature of the crash (crash dump vs. no crash dump). Either we need the scrollbars or its timing related. Changing CRASH_WITH_DUMP=true also causes a crash dump to be produced. The difference with this flag set to true, is that during the SWT.SetData callback we set 0 tree elements instead of 1. I.e. set CRASH_WITH_DUMP=true and the snippet reproduces bug 545919. Set it to =false and the snippet reproduces this bug. Note that in our product we ran into this with a different stack trace: at org.eclipse.swt.widgets.Tree.setItemCount(Tree.java:3211) at org.eclipse.swt.widgets.TreeItem.setItemCount(TreeItem.java:1634) at org.eclipse.jface.viewers.TreeViewer.lambda$2(TreeViewer.java:392) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:358) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1410) at org.eclipse.jface.viewers.TreeViewer.setChildCount(TreeViewer.java:384) at XXX // *** OUR PRODUCT SPECIFIES CHILD COUNT HERE at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.lambda$1(TreeViewer.java:258) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5664) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1386) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1395) at org.eclipse.swt.widgets.Tree.checkData(Tree.java:331) at org.eclipse.swt.widgets.Tree.cellDataProc(Tree.java:264) at org.eclipse.swt.widgets.Display.cellDataProc(Display.java:884) at org.eclipse.swt.internal.gtk.GTK._gtk_tree_store_remove(Native Method) at org.eclipse.swt.internal.gtk.GTK.gtk_tree_store_remove(GTK.java:7283) at org.eclipse.swt.widgets.Tree.destroyItem(Tree.java:1123) at org.eclipse.swt.widgets.TreeItem.destroyWidget(TreeItem.java:372) at org.eclipse.swt.widgets.Widget.release(Widget.java:1213) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:522) at org.eclipse.swt.widgets.Tree.remove(Tree.java:2718) at org.eclipse.swt.widgets.Tree.setItemCount(Tree.java:3226) at org.eclipse.swt.widgets.TreeItem.setItemCount(TreeItem.java:1634) at org.eclipse.jface.viewers.TreeViewer.lambda$2(TreeViewer.java:392) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:358) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1410) at org.eclipse.jface.viewers.TreeViewer.setChildCount(TreeViewer.java:384) at XXX // *** OUR PRODUCT SPECIFIES CHILD COUNT HERE at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.lambda$1(TreeViewer.java:258) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5664) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1386) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1395) at org.eclipse.swt.widgets.Tree.checkData(Tree.java:331) at org.eclipse.swt.widgets.TreeItem.getItemCount(TreeItem.java:779) at org.eclipse.jface.viewers.TreeViewer.replace(TreeViewer.java:463) at XXX // *** OUR PRODUCT REPLACES A TREE ITEM HERE at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.lambda$1(TreeViewer.java:258) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5664) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1386) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1395) at org.eclipse.swt.widgets.Tree.checkData(Tree.java:331) at org.eclipse.swt.widgets.Tree.cellDataProc(Tree.java:264) at org.eclipse.swt.widgets.Display.cellDataProc(Display.java:884) at org.eclipse.swt.internal.gtk.GTK._gtk_tree_store_remove(Native Method) at org.eclipse.swt.internal.gtk.GTK.gtk_tree_store_remove(GTK.java:7283) at org.eclipse.swt.widgets.Tree.destroyItem(Tree.java:1123) at org.eclipse.swt.widgets.TreeItem.destroyWidget(TreeItem.java:372) at org.eclipse.swt.widgets.Widget.release(Widget.java:1213) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:522) at org.eclipse.swt.widgets.Tree.remove(Tree.java:2718) at org.eclipse.swt.widgets.Tree.setItemCount(Tree.java:3226) at org.eclipse.swt.widgets.Tree.setItemCount(Tree.java:3269) at org.eclipse.jface.viewers.TreeViewer.lambda$2(TreeViewer.java:386) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:358) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1410) at org.eclipse.jface.viewers.TreeViewer.setChildCount(TreeViewer.java:384) at XXX // *** OUR PRODUCT SPECIFIES CHILD COUNT HERE at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateChildCount(TreeViewer.java:1019) at org.eclipse.jface.viewers.TreeViewer.virtualRefreshExpandedItems(TreeViewer.java:695) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:674) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1929) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1886) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1872) at org.eclipse.jface.viewers.StructuredViewer.lambda$2(StructuredViewer.java:1510) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1449) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:363) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1410) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1510) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:526) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1469) ... Data changes in out product, which triggers a tree viewer update in a UI job This stack trace is very clear cut, there is an item being destroyed on the stack trace and then a chain of listeners is called. In my snippet the call to the SWT.SetData listener is coming from the main GTK+ loop. There is no item destruction on the stack.
Created attachment 278071 [details] Snippet to reproduce the problem with. Run and click on the only button, observe standard error output.
This is definitely timing related. Play around with the original number of items in the tree, right now I can't reproduce with 7 but I can reproduce with 10.
Created attachment 278072 [details] Video showing the problem when using the attached snippet in Eclipse 4.7.3. Behaviour varies based on number of elements in the tree. I can also reproduce on: Eclipse SDK Version: Oxygen.3 (4.7.3) Build id: M20180221-1700 Again, the initial number of elements in the tree varies. Play around with some numbers between 10 and 50. Do note that on 4.7.3 setting the last element to be selected (done by the reproduction snippet) does not automatically scroll the tree to the bottom. I have to scroll manually to the button, before clicking on the snippet button, in order to reproduce the behaviour with 4.7.3.
Stack trace in GTK: Thread #22 [java] 28324 [core: 0] (Suspended : Breakpoint) gtk_tree_store_get_path() at gtktreestore.c:597 0x7fffa84bade3 gtk_cell_area_real_apply_attributes() at gtkcellarea.c:1,290 0x7fffa82a9bdf gtk_cell_area_box_apply_attributes() at gtkcellareabox.c:1,311 0x7fffa82af8af _gtk_marshal_VOID__OBJECT_BOXED_BOOLEAN_BOOLEANv() at gtkmarshalers.c:5,027 0x7fffa83a53f8 _g_closure_invoke_va() at gclosure.c:867 0x7fffa08acb97 g_signal_emit_valist() at gsignal.c:3,300 0x7fffa08c6157 g_signal_emit() at gsignal.c:3,447 0x7fffa08c6ddf gtk_cell_area_apply_attributes() at gtkcellarea.c:2,373 0x7fffa82ab824 gtk_tree_view_column_cell_set_cell_data() at gtktreeviewcolumn.c:2,820 0x7fffa84dc3d9 gtk_tree_view_bin_draw() at gtktreeview.c:5,173 0x7fffa84d30d7 draw_bin() at gtktreeview.c:5,608 0x7fffa84d475d _gtk_pixel_cache_repaint() at gtkpixelcache.c:357 0x7fffa83f8bff _gtk_pixel_cache_draw() at gtkpixelcache.c:447 0x7fffa83f8bff gtk_tree_view_draw() at gtktreeview.c:5,651 0x7fffa84c0988 _gtk_marshal_BOOLEAN__BOXED() at gtkmarshalers.c:86 0x7fffa839f055 gtk_widget_draw_marshaller() at gtkwidget.c:939 0x7fffa84e22ff g_closure_invoke() at gclosure.c:804 0x7fffa08ac8e2 signal_emit_unlocked_R() at gsignal.c:3,673 0x7fffa08be83b g_signal_emit_valist() at gsignal.c:3,401 0x7fffa08c67dc g_signal_emit() at gsignal.c:3,447 0x7fffa08c6ddf gtk_widget_draw_internal() at gtkwidget.c:7,011 0x7fffa84ed04a gtk_container_propagate_draw() at gtkcontainer.c:3,838 0x7fffa82de084 gtk_container_draw() at gtkcontainer.c:3,658 0x7fffa82de132 gtk_scrolled_window_render() at gtkscrolledwindow.c:2,089 0x7fffa842530b gtk_css_custom_gadget_draw() at gtkcsscustomgadget.c:159 0x7fffa82e2ee1 gtk_css_gadget_draw() at gtkcssgadget.c:877 0x7fffa82e7dd1 gtk_scrolled_window_draw() at gtkscrolledwindow.c:3,001 0x7fffa8423881 gtk_widget_draw_internal() at gtkwidget.c:7,018 0x7fffa84ece28 gtk_container_propagate_draw() at gtkcontainer.c:3,838 0x7fffa82de084 gtk_container_draw() at gtkcontainer.c:3,658 0x7fffa82de132 gtk_widget_draw_internal() at gtkwidget.c:7,018 0x7fffa84ece28 gtk_container_propagate_draw() at gtkcontainer.c:3,838 0x7fffa82de084 gtk_container_draw() at gtkcontainer.c:3,658 0x7fffa82de132 _gtk_marshal_BOOLEAN__BOXED() at gtkmarshalers.c:86 0x7fffa839f055 gtk_widget_draw_marshaller() at gtkwidget.c:939 0x7fffa84e22ff g_closure_invoke() at gclosure.c:804 0x7fffa08ac968 signal_emit_unlocked_R() at gsignal.c:3,673 0x7fffa08be83b g_signal_emit_valist() at gsignal.c:3,401 0x7fffa08c67dc g_signal_emit() at gsignal.c:3,447 0x7fffa08c6ddf gtk_widget_draw_internal() at gtkwidget.c:7,011 0x7fffa84ed04a gtk_container_propagate_draw() at gtkcontainer.c:3,838 0x7fffa82de084 gtk_container_draw() at gtkcontainer.c:3,658 0x7fffa82de132 gtk_scrolled_window_render() at gtkscrolledwindow.c:2,089 0x7fffa842530b gtk_css_custom_gadget_draw() at gtkcsscustomgadget.c:159 0x7fffa82e2ee1 gtk_css_gadget_draw() at gtkcssgadget.c:877 0x7fffa82e7dd1 gtk_scrolled_window_draw() at gtkscrolledwindow.c:3,001 0x7fffa8423881 gtk_widget_draw_internal() at gtkwidget.c:7,018 0x7fffa84ece28 gtk_container_propagate_draw() at gtkcontainer.c:3,838 0x7fffa82de084 gtk_container_draw() at gtkcontainer.c:3,658 0x7fffa82de132 gtk_box_draw_contents() at gtkbox.c:448 0x7fffa8291064 gtk_css_custom_gadget_draw() at gtkcsscustomgadget.c:159 0x7fffa82e2ee1 gtk_css_gadget_draw() at gtkcssgadget.c:877 0x7fffa82e7dd1 gtk_box_draw() at gtkbox.c:457 0x7fffa82938f1 gtk_widget_draw_internal() at gtkwidget.c:7,018 0x7fffa84ece28 gtk_container_propagate_draw() at gtkcontainer.c:3,838 0x7fffa82de084 gtk_container_draw() at gtkcontainer.c:3,658 0x7fffa82de132 gtk_window_draw() at gtkwindow.c:10,212 0x7fffa84fc6c9 gtk_widget_draw_internal() at gtkwidget.c:7,018 0x7fffa84ece28 gtk_widget_render() at gtkwidget.c:17,514 0x7fffa84f80ce gtk_main_do_event() at gtkmain.c:1,824 0x7fffa839e14b Java_org_eclipse_swt_internal_gtk_GTK__1gtk_1main_1do_1event() at 0x7fffd44dc10d 0x7fffe1018407 0x7ffff7fcbb70 0x7ffff7fcba68 0x7ffff7fcba70 0x0 Not really enlightening so far.
Eric, on the GTK+ stack trace I see we are emitting the signal: SIGNAL_APPLY_ATTRIBUTES In the SWT code for there is a blocked signal: "row-changed" (see org.eclipse.swt.widgets.Tree.checkData(TreeItem)) Should we maybe also block the signal which is on the GTK+ stack trace (SIGNAL_APPLY_ATTRIBUTES)? I do see the following code: boolean checkData (TreeItem item) { if (item.cached) return true; if ((style & SWT.VIRTUAL) != 0) { item.cached = true; Since TreeItem.cached is set to true, maybe its expected that Tree.checkData loads/applies attributes?
Do you mean the "apply-attributes" signal in GtkCellArea? It's worth a try, though I have a feeling it could have other consequences.
New Gerrit change created: https://git.eclipse.org/r/139847
Gerrit change https://git.eclipse.org/r/139847 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cb06a2f04ad9dc609519396126b5400dbbaf8063
(In reply to Eclipse Genie from comment #27) > Gerrit change https://git.eclipse.org/r/139847 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=cb06a2f04ad9dc609519396126b5400dbbaf8063 In master now, thanks for the patch!
We have 2 regressions in UI tests on all 3 GTK builds (means: the fails are stable). https://download.eclipse.org/eclipse/downloads/drops4/I20190403-1800/testresults/html/org.eclipse.ui.tests_ep412I-unit-cen64-gtk3-java8_linux.gtk.x86_64_8.0.html Cannot remove a tree item while its data is being set. At item 0 in range [0, 10). org.eclipse.swt.SWTException: Cannot remove a tree item while its data is being set. At item 0 in range [0, 10). at org.eclipse.swt.widgets.Tree.checkSetDataInProcessBeforeRemoval(Tree.java:4221) at org.eclipse.swt.widgets.Tree.remove(Tree.java:2832) at org.eclipse.swt.widgets.Tree.setItemCount(Tree.java:3359) at org.eclipse.swt.widgets.TreeItem.setItemCount(TreeItem.java:1659) at org.eclipse.jface.viewers.TreeViewer.lambda$2(TreeViewer.java:392) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1448) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:363) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1409) at org.eclipse.jface.viewers.TreeViewer.setChildCount(TreeViewer.java:384) at org.eclipse.jface.tests.viewers.TestModelLazyTreeContentProvider.updateElement(TestModelLazyTreeContentProvider.java:37) at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:596) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:766) at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:1681) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2545) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:3014) at org.eclipse.jface.viewers.TreeViewer.replace(TreeViewer.java:490) at org.eclipse.jface.tests.viewers.TestModelLazyTreeContentProvider.updateElement(TestModelLazyTreeContentProvider.java:36) at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.lambda$1(TreeViewer.java:258) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5933) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1399) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1425) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1408) at org.eclipse.swt.widgets.Tree.checkData(Tree.java:333) at org.eclipse.swt.widgets.Tree.cellDataProc(Tree.java:265) at org.eclipse.swt.widgets.Display.cellDataProc(Display.java:893) at org.eclipse.swt.internal.gtk.GTK._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.GTK.gtk_main_do_event(GTK.java:4179) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1409) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1609) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4721) at org.eclipse.ui.tests.harness.util.DisplayHelper.driveEventQueue(DisplayHelper.java:177) at org.eclipse.ui.tests.harness.util.DisplayHelper.waitForCondition(DisplayHelper.java:78) at org.eclipse.jface.tests.viewers.StructuredViewerTest.bulkChange(StructuredViewerTest.java:124) at org.eclipse.jface.tests.viewers.StructuredViewerTest.testWorldChanged(StructuredViewerTest.java:526) at org.eclipse.jface.tests.viewers.VirtualLazyTreeViewerTest.testWorldChanged(VirtualLazyTreeViewerTest.java:224) Cannot remove a tree item while its data is being set. At item 0 in range [0, 10). org.eclipse.swt.SWTException: Cannot remove a tree item while its data is being set. At item 0 in range [0, 10). at org.eclipse.swt.widgets.Tree.checkSetDataInProcessBeforeRemoval(Tree.java:4221) at org.eclipse.swt.widgets.Tree.remove(Tree.java:2832) at org.eclipse.swt.widgets.Tree.setItemCount(Tree.java:3359) at org.eclipse.swt.widgets.TreeItem.setItemCount(TreeItem.java:1659) at org.eclipse.jface.viewers.TreeViewer.lambda$2(TreeViewer.java:392) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1448) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:363) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1409) at org.eclipse.jface.viewers.TreeViewer.setChildCount(TreeViewer.java:384) at org.eclipse.jface.tests.viewers.TestModelLazyTreeContentProvider.updateElement(TestModelLazyTreeContentProvider.java:37) at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:596) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:766) at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:1681) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2545) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:3014) at org.eclipse.jface.viewers.TreeViewer.replace(TreeViewer.java:490) at org.eclipse.jface.tests.viewers.TestModelLazyTreeContentProvider.updateElement(TestModelLazyTreeContentProvider.java:36) at org.eclipse.jface.viewers.TreeViewer.virtualLazyUpdateWidget(TreeViewer.java:992) at org.eclipse.jface.viewers.TreeViewer.lambda$1(TreeViewer.java:258) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5933) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1399) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1425) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1408) at org.eclipse.swt.widgets.Tree.checkData(Tree.java:333) at org.eclipse.swt.widgets.Tree.cellDataProc(Tree.java:265) at org.eclipse.swt.widgets.Display.cellDataProc(Display.java:893) at org.eclipse.swt.internal.gtk.GTK._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.GTK.gtk_main_do_event(GTK.java:4179) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1409) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1609) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4721) at org.eclipse.ui.tests.harness.util.DisplayHelper.driveEventQueue(DisplayHelper.java:177) at org.eclipse.ui.tests.harness.util.DisplayHelper.waitForCondition(DisplayHelper.java:78) at org.eclipse.jface.tests.viewers.StructuredViewerTest.bulkChange(StructuredViewerTest.java:124) at org.eclipse.jface.tests.viewers.StructuredViewerTest.testSomeChildrenChanged(StructuredViewerTest.java:503)
I'll take a look today.
The initial patch was located directly after the following code in Tree.remove(): GTK.gtk_tree_model_iter_nth_child (modelHandle, iter, parentIter, start); int[] value = new int[1]; GTK.gtk_tree_model_get (modelHandle, iter, ID_COLUMN, value, -1); TreeItem item = value [0] != -1 ? items [value [0]] : null; My change which uses Tree.items is too naive it seems. I'll try asking the GTK+ model for the item, as in this code.
New Gerrit change created: https://git.eclipse.org/r/140045
Gerrit change https://git.eclipse.org/r/140045 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f47aa33d971816803c1bcb5bb4c01e3cad5b3cc2
Wait a bit and close this then?
(In reply to Simeon Andreev from comment #34) > Wait a bit and close this then? Yes. I'm building new snapshot for us, and will run all tests over the weekend. On Monday we will see :-) NB: Please check if this patch also addresses bug 545919.
> NB: Please check if this patch also addresses bug 545919. Checked, I see an SWT exception instead of a crash. I'll close bug 545919 as duplicate.
*** Bug 545919 has been marked as a duplicate of this bug. ***
(In reply to Simeon Andreev from comment #36) > > NB: Please check if this patch also addresses bug 545919. > > Checked, I see an SWT exception instead of a crash. Perfect.
Looks good, we have no issues with tests on eclipse.org and with our own product builds.
Verified in I20190407-1800.
