Community
Participate
Working Groups
M9 I already noticed that in previous builds but I havn't found a reproduceable test case yet. At some time all my decorations become stale. There isn't anything logged or printed to the console. I noticed that with the following behavior. - Views (Package Explorer, Ouline) still show warning/error decoration for elements that are fixed (editor annotation bar is clean). - The editor icon shows wrong error/warning decoration. - Views (Package Explorer, Navigator) loose the Team decorations from my Team plugin (eclipse-ccase.sf.net) or the arn't updated anymore.
Warning and errors are handled by the label provider - not the error mechanism - this would be a problem with the package explorer not refrshing its content enough.
Moving to JDT for the error/warning "decorations". Tod, the last point was about team decorations. Should Gunnar open a separate PR for this?
No - I expect it is a general refresh not happening.
Gunnar, there is a difference between errors shown in the packages view and in the editor. The editor shows the state of the current CU content whereas views (like package explorer, outliner, ...) show the build state. So they are only in sync after a build. Is this the case in your scenario ? If not, what happens to other upates. For example if you change the name of a method does the package explorer and the Outline reflect these changes?
No I don't mean the editor annotations. They are correct every time. I mean the icon in the editor tab item (in the CTabFolder). I'm working with auto-build on so they sould be in synch after a save but they arn't. It seems that only the decorations become stale. Labels are updated correctly.
Gunnar, since I can't reproduce the problem its hard for use to know where to look at. One additional question: do the errors show up/disappear in the problems view (e.g does the problems view update correctly) ?
I believe it's a platform problem. Maybe the decoration scheduler job? I had a moment right now where all jobs seem to wait fo something (see bug 63633 attachment 11265 [details]). I thought it would be the workspace build job but this time I had to kill the decoration scheduler job to got other jobs working again. After that, no decorations where ever updated again. Again, let me recall that my problem is NOT specific to problem decorations or to JDT views. ALL decorations become stale (also Team decorations) and also in the Resource Navigator.
I got it again, but this time all decorations painted fine again after killing the "decoration scheduler" job. I also noticed that the Problems view also shows old information. The Java editor is the only tool that is up-to-date with its annotation model. Maybe what I'm seeing is that some job is blocking all things. Or some job is waiting/sleeping and doesn't get executed?
The Java editor shows the errors based on the current content of the CU. The errors are produced in the reconciler thread, which isn't a Job. The Editor doesn't rely on any build state. The fact that the problems view shows old information too shows that this isn't a package explorer refresh problem. Either the build didn't finish or the marker deltas aren't sent out correctly. Gunnar, when you see this happening again can you try to produce a VM dump. This would help narrowing down the problem. Moving to Platform/UI.
I'll track this one although it sounds to me like it is a Core or JDT core issue as nothing is getting updated.
Bug 64559 describes a problem with refreshes of markers after builds in 20040527.
Adding Bug 64540 to this list as this looks like the cause. It appears that auto builds are being pertiodically cancelled leaving your markers out of date.
I noticed this bug is marked as blocked by bug 64540. We have a fix for this bug, but we believe that bug was only introduced on May 26th. I don't know if this bug is actually related or not.
bug 57656 might be the cause
I'm sorry bug 57656 might not be the root cause. There are still other problems in the Package Explorer and Outline view in RC1. Example: After beeing hit by bug 57656 I got the sleeping jobs working fine again. But the Package Explorer and the ouline view still did show old problem decorations for an element without any problems. Several changes and saves (which caused builds) didn't update the problem decorations in the Packages Explorer and Outline view. The Problems view was correct. It did not show any problems for the selected resource. Afte closing and reopening the Package Explorer and the Outline View the warning ticks were displayed correctly.
When the Package explorer gets out of sync for whatever reason it will not come back into sync by simply changing code and trigger a build. The problem marker manager listen to marker changes and tries to compute a minimal refresh for the shown label. So as long as nothing has changed for an element (field, method, ...) showing an error it will not be refreshed even if the file is rebuild. So the only way to come back in sync again is to close/open the view or to trigger a rebuild all.
*** Bug 62061 has been marked as a duplicate of this bug. ***
Again, this is a core problem. Even the Resource Navigator doesn't update anymore. I closed all perspectives (which closes all views and editors). After reopening the Resource perspective not Team decorations are drawn in the Resource Navigator. After reopening the Java perspective, no Team decorations are drawn in the Package Explorer (but Problem decorations are drawn). This indicates that it can also be a problem in the DecoratorManager because all views and only decorations contributed by plug-ins are affected. Build in decorations (problem decorations in Package Explorer) are not stale. The problem with stale problem decorations int Package Explorer and Outline View I see in 3.0 RC1 might be a seperate issue (bug 62061 might not be a duplicate).
addendum to comment #19: The problem decorations are only painted initially but not updated in the Java views although they are removed from the Problems view. I think the LabelProviderChangedEvents are not handled anymore. I also tried to cancel the "Decoration calulation" job, close all perspective and reopen one, but it didn't solve the problem. The job is never started again.
Killing the the decoration scheduling job could very easily mess up your decorations as the updates generated from it will not fire. I'm adding Jean Michel to the list as if the CVS decorator can block on another job then decorations will be blocked waiting on it to finish. I think Dirk may have seen a similiar case where a sync blocked the decorator thread
*** Bug 67073 has been marked as a duplicate of this bug. ***
Gunnar, Can you recreate this problem on RC2? If this problem still occurs please describe the steps you took to cause the problem.
On 2nd read Bug #67073 mentions that this problem shows up on RC2. However, we still need a test case.
*** Bug 67435 has been marked as a duplicate of this bug. ***
*** Bug 67471 has been marked as a duplicate of this bug. ***
I was asked by Jean-Michel Lemieux in bug 67435 to verify if error/warning decorations were also out-of-sync and i can confirm that when i loose the team decorators also the error decorators go out of sync. But while it's enough to perform a project "clean" to force a rebuild to have back the error decorators in sync, there's no way to have back team decorators but restart eclipse.
Dont you think this is a "must fix" for 3.0
Created attachment 12366 [details] Stale decorators thread dump If it can help i've got a thread dump after all the team decorators wiped out from the Package explorer view.
In case you suspect multithreading issues, my machine is a win XP P4 running in hyperthreaded mode
Has anyone seen this also got anything to thier log? If a Thread had died that might explain this as well. Gabrielle or Gunnar is there anything about your machines that are different we should look at as well?
Nothing is logged. That's the problem. It just stops. Switching label decorations on or off in the preferences doesn't solve the problem. I have to restart Eclipse. Machine is a P4 2,8 GHz with Hyperthreading, Windows XP, SP1a, 1GB RAM. I see this in all my workspaces. I see this more often in workspaces dealing only with CVS projects than in workspaces with ClearCase projects although I also see this there. It seems like the Decoration Calculation job is sleeping all the time. The ClearCase decorator (for example) continues firering events but it's never ask to decorate elements. Both are lightwight label decorators which may also be a point. Not sure.
My machine is a P4 3.06 GHz with Hyperthreading, Windows XP Pro sp1, 1GB RAM. I don't find anything logged anywhere. About how it happens, i have seen some variations, but it always starts with team decorators. Sometimes all the team decorators disappear suddendly from all the projects, sometimes they begin disappearing in groups from the project i'm working within starting from the leafs and propagating towards the root (considering as the project root the folder containing it) to extend then to the other projects. After this happens, sometimes (but sometimes not) also the warning/error decorators go out of sync, but forcing a project rebuild i've always been able to resync them. No way instead for team decorators, they are irremediably lost and also checking label decorators off and on in the preferences don't get them back. Only restart does.
Thanks very much everyone - this is a big help. Could you also all post the details of the virtual machines you are using? i.e. version number, manufacturer and revision if you know it.
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition java.runtime.version=1.4.2_04-b05 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.specification.version=1.4 java.util.prefs.PreferencesFactory=java.util.prefs.WindowsPreferencesFactory java.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi java.version=1.4.2_04 java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) Client VM java.vm.specification.name=Java Virtual Machine Specification java.vm.specification.vendor=Sun Microsystems Inc. java.vm.specification.version=1.0 java.vm.vendor=Sun Microsystems Inc. java.vm.version=1.4.2_04-b05
Talking to John this morning is this is almost certainly a dup of Bug 57656. I am going to try and get in this state on a hyperthreaded machine and see if switching VMs makes any difference.
Sun 1.4.2_04-b05. I also think that there must be a relation to bug 57656 but I have no clue. In 57656 I got auto building working again by simply canceling the top most sleeping job, which in 90% of the cases was "Decoration Calculation".
1.4.2_04-b05
I have replicated this today using the following parameters Sun 1.4.2 P4 (b5) XP enterprise hyperthreaded 3 Ghz machine. I am now running with the option -Djava.compiler= none so as it turn off the jit and it has not happened to me yet. Could you please try running with this option and see if you get it again?
*** Bug 67576 has been marked as a duplicate of this bug. ***
Indeed turning off the JIT compiler (-Djava.compiler=none) seems to solve the problem. Do you think it's a timing issue specific to the latest Sun VM?
Please forget my last comment (comment #41). I had a situation right now where decorations are gone although the instance is started with "- Djava.compiler=none".
I suspect it is a timing bug that the jit makes worse - thats why I wanted to see if things got better in general without it.
I haven't seen the problem since switching the JIT off
Gunnar would you mind running with the 02 version of the 1.4.1 Sun Vm and seeing if this still happens? I have been using that today and have not seen it yet but there appears to be something different about your workflow that makes these easier too see.
I can also make this happen with the 02 version with the JIT enabled. When I looked in the progress view the decoration thread was sleeping. Cleaning and kicking off a build got me back on track but simple changes did not update the decorators or the error/warning annotations even with auto build on. Enabling/disabling the decorators made no difference either. Note there are two dumps here anager) at org.eclipse.jdi.internal.MirrorImpl.getCommandVM (MirrorImpl.java:276) at org.eclipse.jdi.internal.event.EventQueueImpl.remove (EventQueueImpl.j ava:63) at org.eclipse.jdi.internal.event.EventQueueImpl.remove (EventQueueImpl.j ava:48) at org.eclipse.jdt.internal.debug.core.EventDispatcher.run (EventDispatch er.java:213) at java.lang.Thread.run(Thread.java:534) "Packet Send Manager" prio=5 tid=0x03492b80 nid=0xd10 in Object.wait() [4b0f000. .4b0fd8c] at java.lang.Object.wait(Native Method) - waiting on <0x14805ac0> (a org.eclipse.jdi.internal.connect.PacketSend Manager) at java.lang.Object.wait(Object.java:429) at org.eclipse.jdi.internal.connect.PacketSendManager.sendAvailablePacke ts(PacketSendManager.java:94) - locked <0x14805ac0> (a org.eclipse.jdi.internal.connect.PacketSendMana ger) at org.eclipse.jdi.internal.connect.PacketSendManager.run (PacketSendMana ger.java:54) at java.lang.Thread.run(Thread.java:534) "Packet Receive Manager" prio=5 tid=0x03e32bb8 nid=0xddc runnable [4acf000..4acf d8c] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at java.io.DataInputStream.readInt(DataInputStream.java:443) at org.eclipse.jdi.internal.jdwp.JdwpPacket.read(JdwpPacket.java:124) at org.eclipse.jdi.internal.connect.PacketReceiveManager.readAvailablePa cket(PacketReceiveManager.java:224) at org.eclipse.jdi.internal.connect.PacketReceiveManager.run (PacketRecei veManager.java:70) at java.lang.Thread.run(Thread.java:534) "Worker-67" prio=5 tid=0x03310080 nid=0xc84 in Object.wait() [4a8f000..4a8fd8c] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:166) - locked <0x1295e820> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob (WorkerPool.java:19 3) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:59) "Console Polling Thread" prio=7 tid=0x02f09cd0 nid=0xf04 waiting on condition [4 9ef000..49efd8c] at java.lang.Thread.sleep(Native Method) at org.eclipse.debug.internal.ui.views.console.ConsoleDocumentPartitione r.pollAndSleep(ConsoleDocumentPartitioner.java:565) at org.eclipse.debug.internal.ui.views.console.ConsoleDocumentPartitione r$1.run(ConsoleDocumentPartitioner.java:549) at java.lang.Thread.run(Thread.java:534) "Input Stream Monitor" prio=5 tid=0x03e484b8 nid=0xb64 in Object.wait() [486f000 ..486fd8c] at java.lang.Object.wait(Native Method) - waiting on <0x14805ca0> (a java.lang.Object) at java.lang.Object.wait(Object.java:429) at org.eclipse.debug.internal.core.InputStreamMonitor.writeNext (InputStr eamMonitor.java:124) - locked <0x14805ca0> (a java.lang.Object) at org.eclipse.debug.internal.core.InputStreamMonitor.write (InputStreamM onitor.java:99) at org.eclipse.debug.internal.core.InputStreamMonitor$1.run (InputStreamM onitor.java:75) at java.lang.Thread.run(Thread.java:534) "Output Stream Monitor" prio=5 tid=0x0349a008 nid=0xed8 runnable [482f000..482fd 8c] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:177) at org.eclipse.debug.internal.core.OutputStreamMonitor.read (OutputStream Monitor.java:132) at org.eclipse.debug.internal.core.OutputStreamMonitor.access$1 (OutputSt reamMonitor.java:124) at org.eclipse.debug.internal.core.OutputStreamMonitor$1.run (OutputStrea mMonitor.java:177) at java.lang.Thread.run(Thread.java:534) "Output Stream Monitor" prio=5 tid=0x03f469b0 nid=0x31c runnable [3cdf000..3cdfd 8c] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:194) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked <0x14809df0> (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:90) at org.eclipse.debug.internal.core.OutputStreamMonitor.read (OutputStream Monitor.java:132) at org.eclipse.debug.internal.core.OutputStreamMonitor.access$1 (OutputSt reamMonitor.java:124) at org.eclipse.debug.internal.core.OutputStreamMonitor$1.run (OutputStrea mMonitor.java:177) at java.lang.Thread.run(Thread.java:534) "Worker-66" prio=5 tid=0x02f30970 nid=0xc0c in Object.wait() [3bdf000..3bdfd8c] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:166) - locked <0x1295e820> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob (WorkerPool.java:19 3) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:59) "Worker-65" prio=5 tid=0x034fc578 nid=0xdcc in Object.wait() [3a9f000..3a9fd8c] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:166) - locked <0x1295e820> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob (WorkerPool.java:19 3) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:59) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x04049a30 n id=0xdf4 in Object.wait() [47ef000..47efd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x1472bb08> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x03f5dac8 n id=0xd00 in Object.wait() [47af000..47afd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x146be450> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x034b60d0 n id=0x8fc in Object.wait() [476f000..476fd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x14626d10> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x03dbdea0 n id=0xccc in Object.wait() [471f000..471fd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x145727c0> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x040b1c38 n id=0xbc0 in Object.wait() [46df000..46dfd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x144cd900> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x03e04b28 n id=0xdac in Object.wait() [3d9f000..3d9fd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x1437f528> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x04049c38 n id=0xdbc in Object.wait() [3adf000..3adfd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x142f3f20> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x032a2ca8 n id=0xcb4 in Object.wait() [396f000..396fd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x14270ab0> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x03293d88 n id=0x178 in Object.wait() [39af000..39afd8c] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:175) - locked <0x141cb078> (a org.eclipse.jface.text.reconciler.DirtyRegionQu eue) "Worker-61" prio=5 tid=0x033ceef0 nid=0xa94 runnable [48af000..48afd8c] at java.lang.Win32Process.waitFor(Native Method) at org.eclipse.debug.core.model.RuntimeProcess$ProcessMonitorJob.run (Run timeProcess.java:362) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:66) "Java indexing" daemon prio=4 tid=0x02fa0988 nid=0xc64 in Object.wait() [3a3f000 ..3a3fd8c] at java.lang.Object.wait(Native Method) - waiting on <0x12c75dc0> (a org.eclipse.jdt.internal.core.search.indexi ng.IndexManager) at java.lang.Object.wait(Object.java:429) at org.eclipse.jdt.internal.core.search.processing.JobManager.run (JobMan ager.java:338) - locked <0x12c75dc0> (a org.eclipse.jdt.internal.core.search.indexing.I ndexManager) at java.lang.Thread.run(Thread.java:534) "Reference Cleaner - 2" prio=7 tid=0x03151fb8 nid=0xc10 in Object.wait() [38df00 0..38dfd8c] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x12ab6848> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at org.eclipse.jface.action.ActionContributionItem$ImageCache$ReferenceC leanerThread.run(ActionContributionItem.java:207) "Reference Cleaner - 1" prio=7 tid=0x03147828 nid=0x960 in Object.wait() [389f00 0..389fd8c] at java.lang.Object.wait(Native Method) - waiting on <0x12ab68b8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x12ab68b8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at org.eclipse.jface.action.ActionContributionItem$ImageCache$ReferenceC leanerThread.run(ActionContributionItem.java:207) "Start Level Event Dispatcher" daemon prio=5 tid=0x00a22480 nid=0xbf8 in Object. wait() [30cf000..30cfd8c] at java.lang.Object.wait(Native Method) - waiting on <0x127e8f28> (a org.eclipse.osgi.framework.eventmgr.EventTh read) at java.lang.Object.wait(Object.java:429) at org.eclipse.osgi.framework.eventmgr.EventThread.getNextEvent (EventThr ead.java:162) - locked <0x127e8f28> (a org.eclipse.osgi.framework.eventmgr.EventThread ) at org.eclipse.osgi.framework.eventmgr.EventThread.run (EventThread.java: 100) "Framework Event Dispatcher" daemon prio=5 tid=0x00a1f838 nid=0xbfc in Object.wa it() [308f000..308fd8c] at java.lang.Object.wait(Native Method) - waiting on <0x127e9010> (a org.eclipse.osgi.framework.eventmgr.EventTh read) at java.lang.Object.wait(Object.java:429) at org.eclipse.osgi.framework.eventmgr.EventThread.getNextEvent (EventThr ead.java:162) - locked <0x127e9010> (a org.eclipse.osgi.framework.eventmgr.EventThread ) at org.eclipse.osgi.framework.eventmgr.EventThread.run (EventThread.java: 100) "Signal Dispatcher" daemon prio=10 tid=0x0003d808 nid=0xbb0 waiting on condition [0..0] "Finalizer" daemon prio=9 tid=0x009c04e0 nid=0x47c in Object.wait() [2d4f000..2d 4fd8c] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x1277a5d0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x009bf028 nid=0xbb8 in Object.wait() [2d 0f000..2d0fd8c] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked <0x1277a638> (a java.lang.ref.Reference$Lock) "main" prio=7 tid=0x00035240 nid=0xa84 runnable [7f000..7fc3c] at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method) at org.eclipse.swt.widgets.Display.sleep(Display.java:3036) at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle (WorkbenchAd visor.java:344) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1376) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1346) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.jav a:252) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:96 ) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformAct ivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.ja va:272) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.ja va:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:186) at org.eclipse.core.launcher.Main.run(Main.java:647) at org.eclipse.core.launcher.Main.main(Main.java:631) "VM Thread" prio=5 tid=0x009fb720 nid=0xbc4 runnable "VM Periodic Task Thread" prio=10 tid=0x009fc040 nid=0x73c waiting on condition "Suspend Checker Thread" prio=10 tid=0x009c2a78 nid=0xbcc runnable
**** BEGIN DUMP JOB MANAGER INFORMATION **** Process monitor(4340) state: RUNNING Periodic workspace save.(4) state: SLEEPING Decoration Calculation(15) state: SLEEPING **** END DUMP JOB MANAGER INFORMATION ****
*** Bug 68107 has been marked as a duplicate of this bug. ***
I could not append a patched workbench.jar but I am running this morning with this patch. If you want to try it out apply it to the DecorationScheduler, generate a new workbench.jar from org.eclipse.ui.workbench and replace the one in your plugin.xml. Index: DecorationScheduler.java =================================================================== RCS file: /home/eclipse/org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/decorators/DecorationScheduler.java,v retrieving revision 1.39 diff -u -r1.39 DecorationScheduler.java --- DecorationScheduler.java 20 Apr 2004 17:45:55 -0000 1.39 +++ DecorationScheduler.java 22 Jun 2004 14:24:50 -0000 @@ -128,6 +128,8 @@ awaitingDecoration.add(element); if (shutdown) return; + if(decorationJob.getState() == Job.SLEEPING) + decorationJob.wakeUp(); decorationJob.schedule(); }
*** Bug 68162 has been marked as a duplicate of this bug. ***
*** Bug 62113 has been marked as a duplicate of this bug. ***
This workaround has been released for the 2004-0622-1300 build
Marking fixed for the verfication pass.
Marking verified.
*** Bug 68945 has been marked as a duplicate of this bug. ***
Re: the latest duplicate bug This shouldn't be marked as fixed then, should it?
The latest duplicate was reported against build 200406111814, but the workaround was only released for the 0622 build. Therefore, it is quite possible that it is a duplicate. For all people who have reported this, we would like to hear feedback from anyone who has experienced this problem with the 3.0 release.
I have used the integration build containing the fix and the actual 3.0 release since Monday and have not seen the problem again.
No more occurrences since when using the 0622 build. Now i'm using the 3.0 final release and it works really smooth.
Sorry to say this still seems to be a problem (though less frequent) in 3.0.0 final (Build id: 200406251208). Introducing errors by, for example, commenting out a method that's used by a subclass sometimes doesn't cause appropriate error decorators to appear in the package explorer. Cleaning the source and doing a full rebuild seems to restore the proper decorations. Fixing the problem (by un-commenting the referenced methods) sometimes doesn't remove the error decorations appropriately. Going to the file that references the now-restored methods shows the greyed-out error decorations in the editor (even though all files are saved), and the package explorer still shows an error for the file. Cleaning the source and doing a rebuild fixes it. The only item I see in the Progress view is "Setting build path (Waiting)" which never seems to go away.
David, when this happens, what does the problems view show. Are the errors reported in the problems view ? The waiting job might be related to bug 68505.
I'll reopen. It could be that the job setting the build path has a lock that may block your updates.
The issue in the progress view is Bug 68505 which was a general issue with user jobs (this one is from the BuildPathsPropertyPage) and is not related to your problem (you just managed to find 2 at once...). As Dirk was saying if your problems view is correct this is an issue with the updating of decorations - if not it is likely a builder issue.
I was just at my co-worker's workstation trying to recreate this problem to answer your question and realized his "Build Automatically" flag was off. I am both happy (for you) and embarassed (for us) to say this may have been a false bug report. I'll let you know if he encounters the error again in the next couple of days.
No problem David - you had reported a valid bug after all - Bug 68505. I am going to close this - please reopen if the problem is really happening.
Marking closed
