Community
Participate
Eclipse IDE
Steps to reproduce: 1) get eclipse RC3 (linux gtk on a debian/sid laptop is what I got), unzip and run 2) Navigate to Window/Preferences/Java/Code Generation/Code and Comments 3) Select Types 4) wait for a moment and notice that your favorite load meter shows that the CPU is pegged 5) click edit 6) modify the text 7) click ok 8) notice that the pattern display is not updated and CPU is still pegged 9) Click apply ok and cancel 10) notice that the prferences window doesn't go away 11) click the 'X' in the window decorations for the preferences page 12) notice that the preferences window goes away and CPU goes back down 13) exit eclipse 14) look at .metadata/.log, notice the stack trace !SESSION Mar 21, 2003 02:15:33.672 --------------------------------------------- java.fullversion=J2RE 1.4.0 IBM build cxia32140-20020917a (JIT enabled: jitc) BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en Command-line arguments: -os linux -ws gtk -arch x86 -install file:/home/burner/jdks/eclipse/eclipse/ !ENTRY org.eclipse.ui 4 4 Mar 21, 2003 02:15:33.673 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Mar 21, 2003 02:15:33.713 !MESSAGE Widget is disposed !STACK 0 org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:2320) at org.eclipse.swt.widgets.Control.getDisplay(Control.java(Compiled Code)) at org.eclipse.swt.widgets.Control.getDisplay(Control.java(Compiled Code)) at org.eclipse.swt.widgets.Control.getDisplay(Control.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Tree.setSelection(Tree.java:894) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:226) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:1261) at org.eclipse.jface.viewers.StructuredViewer.setSelectionToWidget(StructuredViewer.java:1053) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:808) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:859) at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.refresh(TreeListDialogField.java:710) at org.eclipse.jdt.internal.ui.preferences.CodeTemplateBlock.edit(CodeTemplateBlock.java:349) at org.eclipse.jdt.internal.ui.preferences.CodeTemplateBlock.doButtonPressed(CodeTemplateBlock.java:332) at org.eclipse.jdt.internal.ui.preferences.CodeTemplateBlock$CodeTemplateAdapter.customButtonPressed(CodeTemplateBlock.java:70) at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.buttonPressed(TreeListDialogField.java:171) at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.doButtonSelected(TreeListDialogField.java:386) at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.access$2(TreeListDialogField.java:382) at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField$2.widgetSelected(TreeListDialogField.java:349) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:91) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java(Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java(Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java(Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.jface.window.Window.runEventLoop(Window.java(Compiled Code)) at org.eclipse.jface.window.Window.open(Window.java:563) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:53) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:456) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContributionItem.java:403) at org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem.java:397) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(ActionContributionItem.java:72) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:913) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1641) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1433) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1402) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:61) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:40) at java.lang.reflect.Method.invoke(Method.java:335) at org.eclipse.core.launcher.Main.basicRun(Main.java:291) at org.eclipse.core.launcher.Main.run(Main.java:747) at org.eclipse.core.launcher.Main.main(Main.java:583)
FYI: The exception is generated when the 'X' is clicked on the window decorations for the preferences window.
This was an RC3 bug fixed in RC3a, apparently
Martin, also the reporter said that the problem is gone in RC3a can you please comnment on the stack trace. May be there is a underlying problem here.
I've not seen such a stacktrace before. It's strange that the tree would be disposed after the edit call. My guess this is a SWT problem
Asking SWT if anything changed here between RC3 and RC3a
The only changes made by SWT between RC3 and RC3a where for motif. I think the stack trace does not show the full problem. When the CPU was pegged there were probably exceptions thrown and caught that altered the code flow and resulted in referenceing a disposed tree. Moving back to JDT UI.
Yeah, if I recall correctly the stack trace occured at step 11/12, so Veronika's probably right.
Veronika, I trried to track this done but I am not able to do so. Here are my findings: - it only happens under Linux-GTK. Motif, Windows and Mac don't reveal the behaviour of CPU pegging and exception. - starting GTK in debug mode and following the steps including 4 and then suspending the main thread brings the CPU back to normal. Unfortunatelly the stack trace doesn't reveal what is done in main. - resuming main brings the CPU back to 100% The first thing we have to track down IMO is the CPU pegging since it makes the dialog unusable. The exception at the end doesn't really cause harm. Veronika any idea what can cause the CPU pegging. It is easy to reproduce and I assume you have better tools and are more familiar with GTk to figure this out. I don't want to move the PR back and forth but without help from SWT it is hard to find out what is going on, especially since it only happens under Linux-GTK
Weird, resize the dialog during the process and the bug doesn't happen.
Another finding: - following steps until step 4 - move the scroll bar of the tree widget down observe: the CPU does back to 0% and the dialog works as expected.
Dirk, please execute this in a shell, "rpm -q glib2".
My configuration is: atk: 1.2.0 glib: 2.2.1 gtk+: 2.2.1 pango: 1.2.1 pkgconfig: 0.15.0
Note that after resizing the dialog or moving the scrollbar you have to wait 2 - 3 seconds until the CPU goes back to 0%.
Use build to reproduce: 200303241446
We are able to confirm that this problem occurs in GTK 2.2.x only. Since this is not an offically supported GTK release at this time, I'm downgrading this PR. Felipe is still looking at the problem.
See also bug 31525.
*** This bug has been marked as a duplicate of 31525 ***
