Summary: | StackOverflow when initializing Java Core | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dirk Baeumer <dirk_baeumer> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P3 | ||||||
Version: | 3.2 | ||||||
Target Milestone: | 3.2 M3 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Dirk Baeumer
2005-10-14 06:13:06 EDT
Created attachment 28280 [details]
The stack trace
Lowering to major since it disabling the org.junit plug-in might not be a common action ;-) 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) ? 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 ... 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. The regression test is rather testVariableInitializer09. Verified for 3.2 M3 using build I20051025-0800+JDT/Core v_618a |