Community
Participate
Working Groups
Build 20021008 Exact steps followed: 1) Open new workspace 2) Go to Preferences-> Plugin Development -> Java Build Path Control 3) Uncheck all check boxes 4) Open new CVS perspective 5) Create anonymous connect to eclipse.org 6) Checkout org.eclipse.core.resources Deadlock. Note: this is not a core bug, I'm just logging it here until I can investigate further. The problem is that someone is launching a ModalContext thread from the UI, and not blocking until it finishes. Then another ModalContext is forked, so we have: ModalContext1: holding Workspace lock, attempts syncExec ModalContext2: waiting on workspace lock UI thread: blocked on ModalContext 2
Created attachment 2134 [details] Java dump file showing deadlock
This is consistently reproducible with simpler steps: 1) Open new workspace 2) Switch to CVS perspective 3) Create anon connection to eclipse.org 4) Checkout org.eclipse.core.resources Deadlock. Attaching another java core dump file.
Created attachment 2135 [details] Another core dump, slightly different deadlock
This is a big mess!! - Checkout operation is just finishing (inside a ModalContext thread) - this kicks off a build process - this cause JavaCore plugin to be started - JavaCore invokes runnables to initialize classpath variables - JavaRuntime changes a preference while initializing its classpath variables - LaunchingPlugin listens to preference changes - It decides to do a full build of all java projects - It invokes a syncExec to do the build - syncExec forks another ModalContext to do the work -> deadlock: The main problem is: - LaunchingPlugin is doing UI stuff (opening a progress dialog) from a non-UI place. (It's blocking a non-UI thread that it doesn't own, and then forks another non-UI thread). A related problem: - JavaCore's startup method is doing complicated things, which is generally hazardous because this code can run at ANY time in ANY thread (and locks may already be acquired). This
*** Bug 24532 has been marked as a duplicate of this bug. ***
Note that in Johns scenario the check out is opening a ProgressMonitorDialog. The LaunchingPlugin then tries to open another ProgressMonitorDialog in a sync exec at which point the deadlock occurs. The scenario in bug 24532 is similar. Closing the preference dialog runs a GlobalBuildAction which opens the first dialog. The builder then does something with the classpath which again triggers the LaunchingPlugin.
Fixed (at least temporarily). Took out the progress monitor. Not clear that there is a way to show build progress at this point.
Please verify, Joe.
Verified.
