Community
Participate
Working Groups
In I20040506, I have a problem with copy/pasted files. If I have a Package Explorer view open that shows the contents of a package as: Aaa Ccc Eee Ggg And chose to copy/paste one of these classes to make a new one called Bbb, then all seems to work OK (I get prompted for the new name, the process seems to complete cleanly, and I can then open Bbb in the Open Type dialog), but the new class *fails* to appear in the Package Explorer list. I can also find no way to make the class appear after this has happened (Refresh etc have no effect). The only thing that works is to shutdown/restart Eclipse. Worse than that, if I create Bbb as above, then although the view does not display the new file, it would appear that its internal state does know about it. Thus, if I then double-click to open Eee, the class that actually opens is Ccc... Eek!
Sounds like a Package Explorer refresh problem. Moving to JDT/UI for comments.
Ian, can you reliable reproduce the bug. I wasn't able to do so. If you can is it possible to zip the test workspace and attach it to the bug report. This would really help to track down this issue.
The fact the the model element for the tree item Eee is actually bound to the new Bbb class shows that the package explorer has processed the delta. It seems the the JFace tree viewer didn't update the label. Moving to Platform/UI for comments.
Ian, do you have any special filters enabled.
Is there anything in the workspace\.metadata\.log file? Please attach anything from the same session. Until recently, viewers would stop updating labels if there was an error when calling the label provider. If this occurred, there should be an entry in the log with a stack trace containing a stack frame from AbstractTreeViewer.doUpdateItem.
I don't have any special filters applied (just things like "hide referenced libraries" - nothing non-standard on specific file types/extensions or anything) Will send stack trace when I can get hold of it
OK, with time difference between me and you, I can't quite narrow down the bit of .log file that would have been generated as this problem arose. There are two exceptions reported in the .log that are getting repeated at (roughly) the time I think this problem happened (and before and since). They are: !SESSION May 12, 2004 13:55:41.79 --------------------------------------------- - java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB Command-line arguments: -showlocation -showlocation -nologo !ENTRY org.eclipse.update.configurator May 12, 2004 13:55:41.79 !MESSAGE ConfigurationParser.parse() error: !STACK 0 java.lang.IllegalArgumentException at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:691) at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) at org.apache.crimson.parser.XMLReaderImpl.parse (XMLReaderImpl.java:448) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at org.eclipse.update.internal.configurator.ConfigurationParser.parse (ConfigurationParser.java:68) at org.eclipse.update.internal.configurator.PlatformConfiguration.loadConfig (PlatformConfiguration.java:1140) at org.eclipse.update.internal.configurator.PlatformConfiguration.initializeCurren t(PlatformConfiguration.java:701) at org.eclipse.update.internal.configurator.PlatformConfiguration.<init> (PlatformConfiguration.java:83) at org.eclipse.update.internal.configurator.PlatformConfiguration.startup (PlatformConfiguration.java:642) at org.eclipse.update.internal.configurator.ConfigurationActivator.getPlatformConf iguration(ConfigurationActivator.java:296) at org.eclipse.update.internal.configurator.ConfigurationActivator.initialize (ConfigurationActivator.java:114) at org.eclipse.update.internal.configurator.ConfigurationActivator.start (ConfigurationActivator.java:68) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run (BundleContextImpl.java:973) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator (BundleContextImpl.java:969) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start (BundleContextImpl.java:952) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker (BundleHost.java:408) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume (AbstractBundle.java:373) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle (Framework.java:999) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles (StartLevelManager.java:571) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL (StartLevelManager.java:482) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel (StartLevelManager.java:272) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent (StartLevelManager.java:442) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent (EventManager.java:153) at org.eclipse.osgi.framework.eventmgr.EventThread$Queued.dispatchEvent (EventThread.java:56) at org.eclipse.osgi.framework.eventmgr.EventThread.run (EventThread.java:107) and (the below entries seem to go together, looking at the timestamps) !ENTRY org.eclipse.ui 4 4 May 13, 2004 14:19:55.456 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 May 13, 2004 14:19:55.456 !MESSAGE Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException: 500) !STACK 0 org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException: 500) at org.eclipse.swt.SWT.error(SWT.java:2689) at org.eclipse.swt.SWT.error(SWT.java:2614) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages (Synchronizer.java:109) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2571) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2276) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1353) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1324) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:243) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:140) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:90) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:283) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:242) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:269) at org.eclipse.core.launcher.Main.run(Main.java:700) at org.eclipse.core.launcher.Main.main(Main.java:684) !ENTRY org.eclipse.ui 4 4 May 13, 2004 14:19:55.456 !MESSAGE *** SWT nested exception !ENTRY org.eclipse.ui 4 0 May 13, 2004 14:19:55.456 !MESSAGE 500 !STACK 0 java.lang.ArrayIndexOutOfBoundsException: 500 at org.eclipse.jface.text.rules.BufferedRuleBasedScanner.read (BufferedRuleBasedScanner.java:118) at org.eclipse.jface.text.rules.WordRule.evaluate(WordRule.java:110) at org.eclipse.jface.text.rules.RuleBasedScanner.nextToken (RuleBasedScanner.java:155) at org.eclipse.jdt.internal.ui.text.AbstractJavaScanner.nextToken (AbstractJavaScanner.java:100) at org.eclipse.jface.text.rules.DefaultDamagerRepairer.createPresentation (DefaultDamagerRepairer.java:166) at org.eclipse.jface.text.presentation.PresentationReconciler.createPresentation (PresentationReconciler.java:446) at org.eclipse.jface.text.presentation.PresentationReconciler.processDamage (PresentationReconciler.java:555) at org.eclipse.jface.text.presentation.PresentationReconciler.access$3 (PresentationReconciler.java:553) at org.eclipse.jface.text.presentation.PresentationReconciler$InternalListener.tex tChanged(PresentationReconciler.java:222) at org.eclipse.jface.text.TextViewer.updateTextListeners (TextViewer.java:2235) at org.eclipse.jface.text.TextViewer.invalidateTextPresentation (TextViewer.java:2928) at org.eclipse.jface.text.source.AnnotationPainter.invalidateTextPresentation (AnnotationPainter.java:783) at org.eclipse.jface.text.source.AnnotationPainter.updatePainting (AnnotationPainter.java:768) at org.eclipse.jface.text.source.AnnotationPainter.access$1 (AnnotationPainter.java:762) at org.eclipse.jface.text.source.AnnotationPainter$1.run (AnnotationPainter.java:871) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages (Synchronizer.java:106) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2571) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2276) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1353) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1324) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:243) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:140) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:90) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:283) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:242) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:269) at org.eclipse.core.launcher.Main.run(Main.java:700) at org.eclipse.core.launcher.Main.main(Main.java:684) Of the two, my .log file has about 3 instances of the SWT "index out of bounds" issue, and a dozen or so of the ConfigurationParser.parse() one. The SWT "index out of bounds" one, though, is the one that occurred most closely to the time that this problem manifest itself - I think. But this is just going on memory, so I could be mistaken.
Created attachment 10813 [details] Eclipse .log file This is my complete log file from the last few days. I created this issue only a little while after the problem arose for me, but this .log file will have been output using GMT timezone. I'll let you do the math to try and trace back from issue creation time to the .log entries :)
The two stacks above do not appear to be related to the viewer update problem. The parser problem occurs on startup and looks to be a dup of bug 61224. Dirk, could you have someone in ZRH look at the second stack above. There are some other ones of interest to ZRH in the log file as well. Tod, could you take a look at the attached log file? It has some failures during decoration. In this case, the failing decorator gets disabled. Could that prevent label updates in the package explorer from happening? Philippe, could you also have a look at these, since the failures are ArrayIndexOutOfBoundsExceptions in org.eclipse.jdt.internal.core.SearchableEnvironment.find?
The second exception happens in Platform/Text. CC Dani and Kai. Can someone of you please comment on the exception.
Looking at the exception form a non text stand-point I doubt that this exception can cause update problems in a JFace tree viewer since the whole stack doesn't contain any JFace Tree Viewer methods.
Dirk is right. This is unrelated to cut/copy/paste in Package Explorer and should be filed as separate bug.
Exception in JDTCore is unrelated, entered separate bug 62861. Ian, please attach steps to reproduce to other bug.
I could reproduce the copy/paste misbehaviour once. The symptoms where that the label of the selected item where different from the label shown in the status line (i.e., the shown label and the object in the data pointer where not consistent).
We had an update problem in M8 where decorators were not firing updates when the tree was being updated (Dani I can't find the Bug - it was the one where the Ctrl-O was updating wrong) but I think it was fixed before 0506. I'll investigate the same case with a failed decorator.
Addition to Erich comment #14. We checked the log and it didn't contain any entries.
I have checked the case below using a decorator in 20040519 that throws an IndexOutOfBoundsException and this does not cause any problems with the labels in the packages or resources view not matching thier entries or with entries not being added.
I have a theory: - in TreeViewer.doUpdateItem, it checks whether the label provider is an IViewerLabelProvider (the new one for optimizing decorations) - DecoratingLabelProvider implements IViewerLabelProvider, and is being used here - in DecoratingLabelProvider.updateLabel, it does not work if decorationReady=delayedDecorator.prepareDecoration is false. - if the queued decoration does not occur due to decorator breakage, the TreeItem will be left with the old text and image Tod, do you know of any way the last step can happen?
The problem that could happen is if the decorator thread dies and the update is never posted. We had a couple of bugs to this effect a while back (which were fixed). We also had an update problem previously where if something had no decoration the update would not be sent - I fixed that a few weeks ago (this is the one I referred to with Dani). So it was possible to make this happen in M8 and early M9 but it should not be now.
It's bug 55576
As there were a series of fixes to updates and decorators in M9 I think this is already fixed but I will leave this open and mark for 3.0 to see if it shows up still post M9.
Closing as it looks like the M9 fixes covered this.
Marking as closed.
