Bug 259607

Summary: Deadlock opening launch configuration dialog
Product: [Eclipse Project] JDT Reporter: Matt Lavin <matt_lavin>
Component: CoreAssignee: Jerome Lanneluc <jerome_lanneluc>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: srikanth_sankaran
Version: 3.5   
Target Milestone: 3.5 M5   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Zipped up javacore text file
none
The stacktrace from the StackOverflowException
none
Proposed fix for the StackOverflowError none

Description Matt Lavin CLA 2008-12-23 16:33:23 EST
Created attachment 121186 [details]
Zipped up javacore text file

I had a Eclipse 3.3 workspace that I was opening using a new install of Eclipse 3.5M4.  When I started the workbench, I noticed that in the status bar of the main window it seemed stuck at 1% initializing the Java models.  I thought that perhaps it was a mistake and I tried to open the launch configuration dialog and Eclipse became completely useless.  I took a thread dump while it was hung and I've attached it to this bug.
Comment 1 Matt Lavin CLA 2008-12-24 09:33:03 EST
This hang seems to happen every time for me, and in the Progress view, it is hung in the task "Initializing Java Tooling" with the subtask "Configuring JRE System Library [J2SE-1.5]"
Comment 2 Matt Lavin CLA 2008-12-24 10:13:35 EST
Because my environment was so hosed, I started experimenting a bit to try to fix the problem.  What I found to get past my hang was to rename the <workspace>/.metadata/.plugins/org.eclipse.jdt.core/variablesAndContainers.dat file to another name.  After doing that, Eclipse did not hang on startup.  After a while of initializing, it threw the StackOverflowException which I will attach.  When I restarted again, everything seems to be working as it should. 
Comment 3 Matt Lavin CLA 2008-12-24 10:15:54 EST
Created attachment 121219 [details]
The stacktrace from the StackOverflowException
Comment 4 Jerome Lanneluc CLA 2009-01-05 11:02:39 EST
The problem reported in comment 0 doesn't seem to be a deadlock according to the attached thread dumps. Threads are still running. It might however have been very slow and give the impression that the initialization was stuck. A slow container initializer could explain this behavior. Only a reproducible test case could tell us for sure.

The StackOverflowError shown in comment 3 is a consequence of the deletion of the variablesAndContainers.dat file. Since the previous container values could not be retrieved, the algorithm entered a deep recursion. It is not an infinite recursion however. If the stack had been big enough, the initialization would have completed.

I will investigate a fix for the StackOverflowError.
Comment 5 Jerome Lanneluc CLA 2009-01-06 12:02:26 EST
Created attachment 121653 [details]
Proposed fix for the StackOverflowError

To verify that the fix is in, only the code can be checked.
Comment 6 Jerome Lanneluc CLA 2009-01-07 04:09:00 EST
Fix released for 3.5M5
Comment 7 Srikanth Sankaran CLA 2009-01-27 06:50:45 EST
Verified for 3.5M5 using I20090125-2000 build