Bug 350612 - OutOfMemoryError while "Initializing Java Tooling"
Summary: OutOfMemoryError while "Initializing Java Tooling"
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.8 M2   Edit
Assignee: Satyam Kandula CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 13:21 EDT by Eric Jain CLA
Modified: 2011-09-14 11:59 EDT (History)
2 users (show)

See Also:
jarthana: review+


Attachments
Proposed patch (2.28 KB, patch)
2011-08-18 08:43 EDT, Satyam Kandula CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Jain CLA 2011-06-28 13:21:29 EDT
Build Identifier: 20110615-0604

My workspace ended up in a state where I would get the error below on each startup, even if setting the maximum heap size to several GB (verified with jvisualvm; no more than 300m were ever used). I was able to fix the problem by deleting the .metadata/.plugins/org.eclipse.jdt.core directory. This directory has about 150 files and is 25mb large, before and after recreating it.

!ENTRY org.eclipse.core.jobs 4 2 2011-06-28 09:49:06.899
!MESSAGE An internal error occurred during: "Initializing Java Tooling".
!STACK 0
java.lang.OutOfMemoryError: Java heap space
	at org.eclipse.jdt.internal.core.index.DiskIndex.readHeaderInfo(DiskIndex.java:787)
	at org.eclipse.jdt.internal.core.index.DiskIndex.initialize(DiskIndex.java:389)
	at org.eclipse.jdt.internal.core.index.Index.<init>(Index.java:97)
	at org.eclipse.jdt.internal.core.search.indexing.IndexManager.getIndex(IndexManager.java:253)
	at org.eclipse.jdt.internal.core.search.indexing.IndexManager.getIndexes(IndexManager.java:317)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(PatternSearchJob.java:81)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.ensureReadyToRun(PatternSearchJob.java:50)
	at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:174)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1135)
	at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:746)
	at org.eclipse.jdt.core.JavaCore.initializeAfterLoad(JavaCore.java:3619)
	at org.eclipse.jdt.internal.ui.InitializeAfterLoadJob$RealJob.run(InitializeAfterLoadJob.java:36)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

!ENTRY org.eclipse.core.jobs 4 2 2011-06-28 09:49:06.930
!MESSAGE An internal error occurred during: "Requesting Java AST from selection".
!STACK 0
java.lang.OutOfMemoryError: Java heap space
	at org.eclipse.jdt.internal.core.index.DiskIndex.readHeaderInfo(DiskIndex.java:787)
	at org.eclipse.jdt.internal.core.index.DiskIndex.initialize(DiskIndex.java:389)
	at org.eclipse.jdt.internal.core.index.Index.<init>(Index.java:97)
	at org.eclipse.jdt.internal.core.search.indexing.IndexManager.getIndex(IndexManager.java:253)
	at org.eclipse.jdt.internal.core.search.indexing.IndexManager.getIndexes(IndexManager.java:317)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(PatternSearchJob.java:81)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.ensureReadyToRun(PatternSearchJob.java:50)
	at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:174)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllSecondaryTypeNames(BasicSearchEngine.java:961)
	at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesSearching(JavaModelManager.java:4542)
	at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypes(JavaModelManager.java:4411)
	at org.eclipse.jdt.internal.core.NameLookup.findSecondaryType(NameLookup.java:591)
	at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:697)
	at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:621)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:103)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:294)
	at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:45)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:132)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getType(PackageBinding.java:127)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.isViewedAsDeprecated(PackageBinding.java:211)
	at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isViewedAsDeprecated(ReferenceBinding.java:1217)
	at org.eclipse.jdt.internal.compiler.ast.ASTNode.isTypeUseDeprecated(ASTNode.java:488)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:394)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:466)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1174)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:681)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1175)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:801)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480)


Reproducible: Always
Comment 1 Ayushman Jain CLA 2011-06-28 14:34:40 EDT
Satyam, is this bug related to bug 108749?
Comment 2 Satyam Kandula CLA 2011-06-29 00:51:38 EDT
(In reply to comment #1)
> Satyam, is this bug related to bug 108749?
This could be related, but need not. I ran into similar problem while fixing 108749, but am not sure.
Comment 3 Satyam Kandula CLA 2011-06-29 00:55:03 EDT
(In reply to comment #0)
> Build Identifier: 20110615-0604
> 
> My workspace ended up in a state where I would get the error below on each
> startup, even if setting the maximum heap size to several GB (verified with
> jvisualvm; no more than 300m were ever used). I was able to fix the problem by
> deleting the .metadata/.plugins/org.eclipse.jdt.core directory. This directory
> has about 150 files and is 25mb large, before and after recreating it.
It looks like one of the index file got corrupted. Is there a possibility to get the contents of this folder? Are there any other entries in the .log file? Can you attach the full .log file?
Comment 4 Eric Jain CLA 2011-06-29 01:31:47 EDT
(In reply to comment #3)
> It looks like one of the index file got corrupted. Is there a possibility to
> get the contents of this folder? Are there any other entries in the .log file?
> Can you attach the full .log file?

The .log file doesn't contain other (relevant) entries.

Is there a non-public place where I can upload the folder?
Comment 5 Satyam Kandula CLA 2011-07-05 11:54:30 EDT
The file 1767898786.index got corrupted. The end of the file contains some xml snippet which shouldn't belong there and there is no chance that JDT/Core would have written. 

By the way, deleting this file should get this problem fixed.
Comment 6 Satyam Kandula CLA 2011-07-18 08:00:26 EDT
(In reply to comment #5)
> The file 1767898786.index got corrupted. The end of the file contains some xml
> snippet which shouldn't belong there and there is no chance that JDT/Core would
> have written. 
> 
> By the way, deleting this file should get this problem fixed.
Hi Eric Jain,
Please look at the end of the file 1767898786.index and see if you have any idea why that content should be getting in there. 
Can you please attach your configuration? 

Thanks,
Satyam.
Comment 7 Eric Jain CLA 2011-07-18 13:23:22 EDT
I'm afraid I don't have any of the original workspace or configuration files anymore, but I'm 100% certain I didn't do anything to any of the index files (didn't even know they existed). I did do a forced shutdown of the system, which might have caused the corruption, somehow.

Regardless of how the index is corrupted, shouldn't Eclipse just clear the index and rebuild it instead of failing?
Comment 8 Satyam Kandula CLA 2011-07-19 00:25:35 EDT
(In reply to comment #7)
> Regardless of how the index is corrupted, shouldn't Eclipse just clear the
> index and rebuild it instead of failing?
Sure, I agree with this and will work on this.
Comment 9 Satyam Kandula CLA 2011-08-18 08:43:35 EDT
Created attachment 201714 [details]
Proposed patch

Added some checks to see if the file is corrupted.
Comment 10 Satyam Kandula CLA 2011-08-18 08:44:20 EDT
Jay, Can you please review the patch?
Comment 11 Jay Arthanareeswaran CLA 2011-08-23 12:15:53 EDT
(In reply to comment #10)
> Jay, Can you please review the patch?

Satyam, how can I make this error occur? I tried polluting some of the index files but didn't help.
Comment 12 Jay Arthanareeswaran CLA 2011-08-24 05:10:13 EDT
I looked at the patch and it looks alright to me.
Comment 13 Satyam Kandula CLA 2011-08-24 06:50:42 EDT
Thanks Jay. 
Released in HEAD.
Comment 14 Ayushman Jain CLA 2011-09-12 22:22:56 EDT
How do I reproduce this? I tried to delete some data in random index files but dont see the error (or an IOException) on startup :(
Comment 15 Ayushman Jain CLA 2011-09-14 11:59:08 EDT
(In reply to comment #14)
> How do I reproduce this? I tried to delete some data in random index files but
> dont see the error (or an IOException) on startup :(

I could test with the index file Satyam sent me. I see the correct IOException instead of the OOME with the following Junit

public void testBug350612() {
		String name = "C:\\Documents and Settings\\Administrator\\Desktop\\Eclipse builds\\eclipse-SDK-I20110911-2000-win32\\eclipse\\1767898786.index";
		try {
			System.out.println("Processing " +name);
			Index d = new Index(name, name, true);
		} catch (Exception e) {
			e.printStackTrace();
		}
		
	}


Hence, verified for 3.8M2 using build I20110911-2000.