Bug 112609 - StackOverflow when initializing Java Core
Summary: StackOverflow when initializing Java Core
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.2 M3   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-14 06:13 EDT by Dirk Baeumer CLA
Modified: 2005-10-28 11:50 EDT (History)
0 users

See Also:

Attachments
The stack trace (362.40 KB, text/plain)
2005-10-14 06:13 EDT, Dirk Baeumer CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2005-10-14 06:13:06 EDT 
I got the following stack overflow when intializing Java Core (see attachement). 

The workspace I started has class path variables for JUnit (see
JUnitHomeInitializer class path initalizer). However, I started it with
junit.org plug-in disabled, hence the JUnitHomeInitializer tries to remove the
class path variable. This results in an endless loop.
Comment 1 Dirk Baeumer CLA 2005-10-14 06:13:45 EDT 
Created attachment 28280 [details]
The stack trace
Comment 2 Dirk Baeumer CLA 2005-10-14 06:14:30 EDT 
Lowering to major since it disabling the org.junit plug-in might not be a common
action ;-)
Comment 3 Jerome Lanneluc CLA 2005-10-14 07:02:24 EDT 
I have trouble reproducing the problem. How can you disable org.junit and still
have JUnitHomeInitializer running (since org.eclipse.jdt.junit is disabled as
well) ?
Comment 4 Dirk Baeumer CLA 2005-10-14 08:14:13 EDT 
You are correct. I missed that I have org.junit in my workspace. What I
basically did is I removed the directory to which the PDE target location
pointed to and then started a second Eclipse from within Eclipse. I got the SOE
in the second Eclipse instance. I can always reproduce this with my test
workspace. So I you want me to set a breakpoint somewhere ...
Comment 5 Jerome Lanneluc CLA 2005-10-17 05:47:56 EDT 
I was able to reproduce by writting a simple regresion test
ClasspathInitializerTests#testVariableInitializer9().

Changed JavaModelManager#variablePut(String, IPath) to store a CP_ENTRY_IGNORE
in the 'variables' map instead of removing the entry, so that we don't attempt
to re-initialize it if the initializer is misbehaving and removing the variable
instead of initializing it.
Comment 6 Olivier Thomann CLA 2005-10-28 11:50:01 EDT 
The regression test is rather testVariableInitializer09.
Verified for 3.2 M3 using build I20051025-0800+JDT/Core v_618a