Bug 28228 - [Dialogs] eclipse hangs on simultaneous save and build
Summary: [Dialogs] eclipse hangs on simultaneous save and build
Status: CLOSED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.1   Edit
Hardware: PC Linux
: P3 critical (vote)
Target Milestone: ---   Edit
Assignee: Tod Creasey CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 29104 29296 (view as bug list)
Depends on: 29252
Blocks:
  Show dependency tree
 
Reported: 2002-12-12 18:42 EST by Brett Porter CLA
Modified: 2005-05-10 14:56 EDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brett Porter CLA 2002-12-12 18:42:35 EST
Eclipse 2.1M3 (but happened in v2.0).

If I hit ctl-S to save the current editor, then ctl-B to build while it is
saving, it hangs with the dialog present. I must kill the java process and
restart eclipse to get out of it. The file has successfully saved.

Build is set to save all editors (yes I know its redundant, but old habits die
hard from anothe IDE). However, it still occurs if this is off.
Build on resource modification is off.

Hitting cancel in the dialog greys the cancel button but doesn't actually cancel
- something that appears true of several functions in Eclipse on Linux.
Comment 1 Sonia Dimitrov CLA 2002-12-13 09:44:15 EST
Are there any entries in your <workspace>/.metadata/.log file?
Comment 2 Brett Porter CLA 2002-12-15 17:30:27 EST
nothing that occurs after startup.

I can reproduce this everytime on more than one linux-gtk installation, and
across different versions of eclipse.
Comment 3 Sonia Dimitrov CLA 2002-12-16 08:27:30 EST
Assigning for further assessment.
Comment 4 Chris McLaren CLA 2003-01-07 15:02:05 EST
not a key bindings issue just because keys are pressed to reproduce the 
bug :). either JDT issue or thread synchronization in dialogs. moving to UI 
[dialogs] for comment.
Comment 5 Tod Creasey CLA 2003-01-07 15:07:24 EST
This is a problem with builders attempting to read a resource that is 
currently locked. Moving to JDT Core
Comment 6 Philipe Mulet CLA 2003-01-08 06:55:26 EST
How could a builder run if the workspace lock is taken by someone else ?
Only a bad timing could cause this. Are save actions performed into 
background ? 

BTW WorkManager#checkIn loop should probably sleep in between 2 attempts, to 
avoid using all CPU for no reason.

Moving to JDT/UI for further analysis.
Comment 7 Dirk Baeumer CLA 2003-01-08 09:19:53 EST
I think this is because under GTK the UI isn't block while the save operation 
is active. Hence the user can start a second operation which will result in the 
deadlock. I am not able to reproduce this under windows. In general the 
workbench is supposed to take care that there can't be two "normal" operations 
running in parallel.

If build on resource modification is off the workbench uses an in place 
progress monitor to report progress. May be this causes some troubles under 
Linux GTK.

Moving back to platform to comment on this.
Comment 8 Tod Creasey CLA 2003-01-08 10:25:54 EST
*** Bug 29104 has been marked as a duplicate of this bug. ***
Comment 9 Sonia Dimitrov CLA 2003-01-08 10:27:05 EST
*** Bug 29146 has been marked as a duplicate of this bug. ***
Comment 10 Randal Cobb CLA 2003-01-08 10:52:23 EST
I believe this may of some help...(see bug 29104) for my original bug of a
simlar nature.

I believe something in either the Eclipse configuration or the project
configuration that gets stored in the workspace folder could be to blame (or a
combination of both).  Last night, I got despirate and tried something I had not
tried since upgrading to M4 from M3.  I made a .tar copy of my entire workspace
folder and deleted it off the system.  I then started Eclipse and it went
through the normal "finalizing install" steps to re-create the workspace.  I
created a new project and checked all my source out of CVS.  Rebuilt the project
as I had in bug 29104 and I get no workbench hangs now.  If I replace the newly
created workspace folder and all of it's contents, I can re-produce the
workbench hang problem listed in 29104.
Comment 11 Tod Creasey CLA 2003-01-08 13:30:30 EST
The SaveOperation is run within the UI Thread and any building is done within
another (I assume lower priority) thread so the issue here appears to be the
fact that we have two threads attempting to access the same file - one to write
(the UI Thread) and one to read (the Thread generated by the builder).

Dirk is right I believe - SaveOperations should be run in a critical mode
because of this.
Comment 12 Tod Creasey CLA 2003-01-08 13:48:05 EST
As another test does this happen when you have auto build on? I suspect it won't
as that will be run in the same thread as the save.

Also when you deadlock if you hit Ctrl-Break from the console you will get the
java dump - appending that to this PR will be of great help.
Comment 13 Brett Porter CLA 2003-01-08 16:28:40 EST
Here is the thread dump. Note that on M4 it seems a little different: I get a
dialog "resource has changed on the filesystem - overwrite?". Obviously this is
because the build is geting in ahead of the save. No matter what I answer, it
still hangs.  afterwards when the progress dialog appears.

I'm surprised nobody can reproduce this - I've done it with 4 versions of
eclipse on 3 machines, new workspace or not, every single time. On the other
hand, I've used eclipse long enough to learn not to press it at the same time now :)

Tod: No, it doesn't happen just hitting save with autobuild on, but it does
happen when I do the ctl-S, ctl-B sequence with autobuild + save on build on

Did kill -3 on the java process to get it:

Full thread dump Java HotSpot(TM) Client VM (1.4.1-b21 mixed mode):

"ModalContext" prio=1 tid=0x0x8715b98 nid=0x112b in Object.wait()
[4e553000..4e553830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44411cd8> (a org.eclipse.core.internal.utils.Semaphore)
        at java.lang.Object.wait(Object.java:426)
        at org.eclipse.core.internal.utils.Semaphore.acquire(Semaphore.java:24)
        - locked <0x44411cd8> (a org.eclipse.core.internal.utils.Semaphore)
        at org.eclipse.core.resources.WorkspaceLock.acquire(WorkspaceLock.java:49)
        at org.eclipse.ui.internal.UIWorkspaceLock.acquire(UIWorkspaceLock.java:40)
        at
org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:80)
        at
org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1527)
        at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:171)
        at
org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:156)
        at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:95)

"org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=1 tid=0x0x86c0f30
nid=0x1129 in Object.wait() [4e4d2000..4e4d2830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44f88228> (a
org.eclipse.jface.text.reconciler.DirtyRegionQueue)
        at
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:161)
        - locked <0x44f88228> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue)

"Decoration" prio=1 tid=0x0x85706d0 nid=0x1123 in Object.wait() [4e445000..4e445830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44d1e3a0> (a
org.eclipse.ui.internal.decorators.DecorationScheduler)
        at java.lang.Object.wait(Object.java:426)
        at
org.eclipse.ui.internal.decorators.DecorationScheduler.next(DecorationScheduler.java:247)
        - locked <0x44d1e3a0> (a
org.eclipse.ui.internal.decorators.DecorationScheduler)
        at
org.eclipse.ui.internal.decorators.DecorationScheduler$3.run(DecorationScheduler.java:273)
        at java.lang.Thread.run(Thread.java:536)

"Java indexing" daemon prio=1 tid=0x0x815c890 nid=0x1122 waiting on condition
[4e37f000..4e37f830]
        at java.lang.Thread.sleep(Native Method)
        at
org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:322)
        at java.lang.Thread.run(Thread.java:536)

"Snapshot" prio=1 tid=0x0x814fb18 nid=0x1121 in Object.wait() [4e2fe000..4e2fe830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x44cd02e0> (a
org.eclipse.core.internal.resources.DelayedSnapshotRunnable)
        at
org.eclipse.core.internal.resources.DelayedSnapshotRunnable.run(DelayedSnapshotRunnable.java:38)
        - locked <0x44cd02e0> (a
org.eclipse.core.internal.resources.DelayedSnapshotRunnable)
        at java.lang.Thread.run(Thread.java:536)

"Signal Dispatcher" daemon prio=1 tid=0x0x80a4648 nid=0x111d waiting on
condition [0..0]

"Finalizer" daemon prio=1 tid=0x0x80863e0 nid=0x111a in Object.wait()
[4c470000..4c470830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x448e5e20> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x448e5e20> (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=1 tid=0x0x8085830 nid=0x1119 in Object.wait()
[41f8d000..41f8d830]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x448e5e88> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:426)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
        - locked <0x448e5e88> (a java.lang.ref.Reference$Lock)

"main" prio=1 tid=0x0x8051bb0 nid=0x1116 waiting on condition [bfffc000..bfffd7b0]
        at java.lang.Thread.sleep(Native Method)
        at org.eclipse.swt.widgets.Display.sleep(Display.java:1674)
        at
org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:131)
        at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:255)
        at
org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:351)
        at
org.eclipse.ui.actions.GlobalBuildAction.doBuildOperation(GlobalBuildAction.java:165)
        at org.eclipse.ui.actions.GlobalBuildAction.run(GlobalBuildAction.java:219)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:769)
        at
org.eclipse.ui.internal.WWinKeyBindingService.invoke(WWinKeyBindingService.java:139)
        at
org.eclipse.ui.internal.WWinKeyBindingService.pressed(WWinKeyBindingService.java:120)
        at
org.eclipse.ui.internal.WWinKeyBindingService$6.widgetSelected(WWinKeyBindingService.java:376)
        at
org.eclipse.ui.internal.AcceleratorMenu$2.handleEvent(AcceleratorMenu.java:55)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:868)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1456)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1278)
        at
org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.runEventLoop(EventLoopProgressMonitor.java:88)
        at
org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.isCanceled(EventLoopProgressMonitor.java:67)
        at
org.eclipse.core.runtime.ProgressMonitorWrapper.isCanceled(ProgressMonitorWrapper.java:87)
        at
org.eclipse.core.runtime.ProgressMonitorWrapper.isCanceled(ProgressMonitorWrapper.java:87)
        at
org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:85)
        at
org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:664)
        at org.eclipse.jdt.internal.core.Openable.save(Openable.java:447)
        at
org.eclipse.jdt.internal.core.CommitWorkingCopyOperation.executeOperation(CommitWorkingCopyOperation.java:121)
        at
org.eclipse.jdt.internal.core.JavaModelOperation.execute(JavaModelOperation.java:326)
        at
org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:626)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1564)
        at
org.eclipse.jdt.internal.core.JavaElement.runOperation(JavaElement.java:562)
        at org.eclipse.jdt.internal.core.WorkingCopy.commit(WorkingCopy.java:78)
        at
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.doSaveDocument(CompilationUnitDocumentProvider.java:925)
        at
org.eclipse.ui.texteditor.AbstractDocumentProvider.saveDocument(AbstractDocumentProvider.java:454)
        at
org.eclipse.ui.texteditor.AbstractTextEditor$11.execute(AbstractTextEditor.java:2772)
        at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:65)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1564)
        at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:79)
        - locked <0x45342970> (a org.eclipse.ui.texteditor.AbstractTextEditor$11)
        at
org.eclipse.ui.texteditor.AbstractTextEditor.performSaveOperation(AbstractTextEditor.java:2790)
        at
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSaveOperation(CompilationUnitEditor.java:849)
        at
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:913)
        - locked <0x44f7bb88> (a org.eclipse.jdt.internal.core.WorkingCopy)
        at org.eclipse.ui.internal.EditorManager$11.run(EditorManager.java:1032)
        at org.eclipse.ui.internal.EditorManager$8.run(EditorManager.java:901)
        at
org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:296)
        at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:246)
        at
org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:432)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:65)
        at
org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:429)
        at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1174)
        at
org.eclipse.ui.internal.EditorManager.runProgressMonitorOperation(EditorManager.java:907)
        at org.eclipse.ui.internal.EditorManager.saveEditor(EditorManager.java:1037)
        at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:2143)
        at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:30)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:769)
        at
org.eclipse.ui.internal.WWinKeyBindingService.invoke(WWinKeyBindingService.java:139)
        at
org.eclipse.ui.internal.WWinKeyBindingService.pressed(WWinKeyBindingService.java:120)
        at
org.eclipse.ui.internal.WWinKeyBindingService$6.widgetSelected(WWinKeyBindingService.java:376)
        at
org.eclipse.ui.internal.AcceleratorMenu$2.handleEvent(AcceleratorMenu.java:55)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:868)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1456)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1278)
        at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1446)
        at org.eclipse.ui.internal.Workbench.run(Workbench.java:1429)
        at
org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845)
        at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462)
        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:247)
        at org.eclipse.core.launcher.Main.run(Main.java:703)
        at org.eclipse.core.launcher.Main.main(Main.java:539)

"VM Thread" prio=1 tid=0x0x80825f0 nid=0x1118 runnable

"VM Periodic Task Thread" prio=1 tid=0x0x80a3278 nid=0x111b waiting on condition
"Suspend Checker Thread" prio=1 tid=0x0x80a3be0 nid=0x111c runnable
Comment 14 John Arthorne CLA 2003-01-08 17:17:37 EST
Ah, this is a side-effect of that strange EventLoopProgressMonitor.  In the
middle of the save operation, this progress monitor is allowing other events to
be dispatched (ostensibly to allow paint events to continue during a long
operation).  Along comes the build operation, and it tries to build.  However it
can't build because the save operation already has the workspace semaphore
(acquired by WorkspaceModifyOperation).  Hence the deadlock.

I think the solution would involve preventing the build event from even being
fired while the save operation is running.  I.e., while save is happening,
freeze the UI in a way that prevents users from invoking other actions.  We
can't be allowing other workspace-modifying actions to be run while the save is
happening.  Since this is only reproducible on GTK, I wonder if it relates to
how key events are dispatched on GTK versus windows??
Comment 15 Tod Creasey CLA 2003-01-09 16:20:22 EST
I have replicated this case - if you do a save from a java editor and then a
Ctrl-B then a Ctrl-B will be serviced even if the UI is not active (i.e. menus
and  the tool bar are disabled).


SWT should not allow accelerators when the Ui is not active.

The reason we see this on GTK only is because the other platforms disbale
accelerators I suspect.
Comment 16 Tod Creasey CLA 2003-01-09 16:25:21 EST
Logged PR to SWT for this case.
Comment 17 Dirk Baeumer CLA 2003-01-10 16:49:25 EST
*** Bug 29296 has been marked as a duplicate of this bug. ***
Comment 18 Adam Kiezun CLA 2003-01-13 11:18:25 EST
this is critical - you cannot work really
the whole ide freezes, you have to kill it and it takes > 20 minutes to get it 
back to shape
Comment 19 Marco Qualizza CLA 2003-01-14 08:51:01 EST
Umm, guys, I hate to tell you, but this isn't a GTK-only problem.  My user-
experience matches Bug #21904 -- sometimes while doing a project refresh, 
sometimes while getting some big updates from CVS, sometimes while opening the 
project (after closing it).  It's had quite a deleterious effect on the general 
Eclipse experience, and has made M4 almost unusable.  My workspace (excluding 
bin) is 82.5 megs (12,000 files).

I run win2k on a P3-866 w/1 Gig of ram.

When I get it from CVS, this is what appears in my log:

!SESSION Jan 10, 2003 14:53:52.864 ---------------------------------------------
java.version=1.3.1_06
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 -install file:C:/Program 
Files/Tools/Development/Eclipse/
!ENTRY org.eclipse.team.cvs.core 1 0 Jan 10, 2003 14:53:52.864
!MESSAGE The resource tree is locked for modifications.
!STACK 0
org.eclipse.team.internal.ccvs.core.CVSException: The resource tree is locked 
for modifications.
	at org.eclipse.team.internal.ccvs.core.CVSException.wrapException
(CVSException.java:92)
	at 
org.eclipse.team.internal.ccvs.core.resources.SynchronizerSyncInfoCache.setCache
dSyncBytes(SynchronizerSyncInfoCache.java:271)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.cacheResourceS
yncForChildren(EclipseSynchronizer.java:623)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.getSyncBytes
(EclipseSynchronizer.java:229)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.getSyncBytes
(EclipseResource.java:222)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isManaged
(EclipseResource.java:181)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isIgnored
(EclipseResource.java:115)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseFile.handleModification
(EclipseFile.java:494)
	at 
org.eclipse.team.internal.ccvs.core.resources.FileModificationManager.contentsCh
anged(FileModificationManager.java:161)
	at 
org.eclipse.team.internal.ccvs.core.resources.FileModificationManager$1.visit
(FileModificationManager.java:77)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:71)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:52)
	at 
org.eclipse.team.internal.ccvs.core.resources.FileModificationManager.resourceCh
anged(FileModificationManager.java:62)
	at org.eclipse.core.internal.events.NotificationManager$1.run
(NotificationManager.java:137)
	at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:852)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at org.eclipse.core.internal.events.NotificationManager.notify
(NotificationManager.java:152)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges
(NotificationManager.java:67)
	at org.eclipse.core.internal.resources.Workspace.broadcastChanges
(Workspace.java:154)
	at org.eclipse.core.internal.resources.Workspace.endOperation
(Workspace.java:870)
	at org.eclipse.core.internal.resources.Workspace.run
(Workspace.java:1570)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run
(WorkspaceModifyOperation.java:79)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:95)
!ENTRY org.eclipse.team.cvs.core 1 0 Jan 10, 2003 15:14:40.974
!MESSAGE The resource tree is locked for modifications.
!STACK 0
org.eclipse.team.internal.ccvs.core.CVSException: The resource tree is locked 
for modifications.
	at org.eclipse.team.internal.ccvs.core.CVSException.wrapException
(CVSException.java:92)
	at 
org.eclipse.team.internal.ccvs.core.resources.SynchronizerSyncInfoCache.setCache
dSyncBytes(SynchronizerSyncInfoCache.java:271)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.cacheResourceS
yncForChildren(EclipseSynchronizer.java:623)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.getSyncBytes
(EclipseSynchronizer.java:229)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.getSyncBytes
(EclipseResource.java:222)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isManaged
(EclipseResource.java:181)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isIgnored
(EclipseResource.java:115)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseFile.handleModification
(EclipseFile.java:494)
	at 
org.eclipse.team.internal.ccvs.core.resources.FileModificationManager.contentsCh
anged(FileModificationManager.java:161)
	at 
org.eclipse.team.internal.ccvs.core.resources.FileModificationManager$1.visit
(FileModificationManager.java:77)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:71)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept
(ResourceDelta.java:52)
	at 
org.eclipse.team.internal.ccvs.core.resources.FileModificationManager.resourceCh
anged(FileModificationManager.java:62)
	at org.eclipse.core.internal.events.NotificationManager$1.run
(NotificationManager.java:137)
	at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:852)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at org.eclipse.core.internal.events.NotificationManager.notify
(NotificationManager.java:152)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges
(NotificationManager.java:67)
	at org.eclipse.core.internal.resources.Workspace.broadcastChanges
(Workspace.java:154)
	at org.eclipse.core.internal.resources.Workspace.endOperation
(Workspace.java:870)
	at org.eclipse.core.internal.resources.Workspace.run
(Workspace.java:1570)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run
(WorkspaceModifyOperation.java:79)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:95)
Comment 20 Tod Creasey CLA 2003-01-14 09:03:43 EST
You are actually reporting a different error - Bug 29212 - to do with 
workspace locks and the CVS decorator. This is also fixed in 20030114.
Comment 21 Marco Qualizza CLA 2003-01-14 09:07:52 EST
*nod* With the CVS part, I could be.  But I *am* getting the same freezing, for
example, when I start Eclipse.  (It's not consistent -- I'll try to get a log
entry next time it does it.)
Comment 22 Marco Qualizza CLA 2003-01-14 09:12:34 EST
I believe that this happened when I did a simple refresh.  I'm not sure, tho -- 
last night was a long night.  When I find something current, and I know what 
action triggered it, I'll post it too  (I appolgoize if this too is a different 
bug -- I'm just going by "I do some sort of refresh, and the darned thing 
freezes.").

!SESSION Jan 13, 2003 10:00:12.44 ----------------------------------------------
java.version=1.3.1_06
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 -install file:C:/Program 
Files/Tools/Development/Eclipse/
!ENTRY org.eclipse.jdt.core 1 2 Jan 13, 2003 10:00:12.44
!MESSAGE Problems occurred when invoking code from plug-
in: "org.eclipse.jdt.core".
!STACK 1
Java Model Exception: Core Exception [code 4] The resource tree is locked for 
modifications.
	at org.eclipse.jdt.core.JavaCore.setClasspathContainer
(JavaCore.java:2705)
	at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize
(JREContainerInitializer.java:59)
	at org.eclipse.jdt.core.JavaCore$1.run(JavaCore.java:827)
	at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:852)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at org.eclipse.jdt.core.JavaCore.getClasspathContainer
(JavaCore.java:822)
	at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath
(JavaProject.java:1471)
	at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath
(JavaProject.java:1401)
	at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath
(JavaProject.java:1377)
	at org.eclipse.jdt.internal.core.DeltaProcessor.initializeRoots
(DeltaProcessor.java:1088)
	at org.eclipse.jdt.internal.core.DeltaProcessor.processResourceDelta
(DeltaProcessor.java:1357)
	at org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged
(DeltaProcessor.java:1628)
	at org.eclipse.core.internal.events.NotificationManager$1.run
(NotificationManager.java:137)
	at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:852)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at org.eclipse.core.internal.events.NotificationManager.notify
(NotificationManager.java:152)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges
(NotificationManager.java:67)
	at org.eclipse.core.internal.resources.Workspace.broadcastChanges
(Workspace.java:154)
	at org.eclipse.core.internal.resources.Workspace.endOperation
(Workspace.java:870)
	at org.eclipse.core.internal.resources.Synchronizer.setSyncInfo
(Synchronizer.java:240)
	at 
org.eclipse.team.internal.ccvs.core.resources.SynchronizerSyncInfoCache.setCache
dSyncBytes(SynchronizerSyncInfoCache.java:268)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.cacheResourceS
yncForChildren(EclipseSynchronizer.java:623)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.getSyncBytes
(EclipseSynchronizer.java:229)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.getSyncBytes
(EclipseResource.java:222)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isManaged
(EclipseResource.java:181)
	at 
org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isIgnored
(EclipseResource.java:115)
	at org.eclipse.team.internal.ccvs.core.resources.EclipseFolder.isIgnored
(EclipseFolder.java:284)
	at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.decorate
(CVSLightweightDecorator.java:172)
	at 
org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate
(LightweightDecoratorDefinition.java:153)
	at 
org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnab
le.run(LightweightDecoratorManager.java:60)
	at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:852)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at 
org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate
(LightweightDecoratorManager.java:220)
	at 
org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations
(LightweightDecoratorManager.java:191)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$3.run
(DecorationScheduler.java:286)
	at java.lang.Thread.run(Thread.java:479)
Comment 23 Tod Creasey CLA 2003-01-23 15:38:04 EST
I have verified in 20030122 that this is no longer na issue. However due to 
some self hosting problems in the is build I can't test as rigourously as I 
would like - plese verify the fix if you have the time.
Comment 24 Tod Creasey CLA 2005-05-10 14:56:09 EDT
Marking closed