Comment 1 Jay Arthanareeswaran 2015-09-09 10:57:36 EDT

Looks like we ended up with a wrong parent/child hierarchy.
Can you please help us with a testcase?

Comment 2 Terry Rosenbaum 2016-08-08 19:33:59 EDT

I saw this error too. It happens often for me. Sorry, I do not know how to reproduce it or reduce it to a simple test case.

The following is from my error log:

eclipse.buildId=4.6.0.I20160606-1100
java.version=1.8.0_102
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product -keyring /Users/terry/.eclipse_keyring
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/terry/.eclipse_keyring

Stack trace from error log:

java.lang.StackOverflowError
	at java.util.HashMap.hash(HashMap.java:338)
	at java.util.HashMap.get(HashMap.java:556)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:503)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:522)
    <above stack trace line repeated 1019 more times>

Comment 3 Stephan Herrmann 2016-08-15 18:11:57 EDT

*** Bug 499395 has been marked as a duplicate of this bug. ***

Comment 4 Ralph Cook 2017-01-05 12:00:58 EST

I am running into this 2-3 times per day at work; I've never seen a bug in eclipse show up this often. It happens when I'm editing; most recently I had put a variable declaration on the line for a 'List<MyClassI>', where my own class was an interface. The interface does not inherit anything. List is java.util.List, used elsewhere in the file I was editing without error.

I'd be happy to give more details as (and if) they're useful, but can't upload the entire set of projects for someone else to look at.

Comment 5 Eclipse Genie 2017-01-22 17:24:40 EST

New Gerrit change created: https://git.eclipse.org/r/89303

Comment 6 Stephan Herrmann 2017-01-22 17:26:57 EST

(In reply to Eclipse Genie from comment #5)
> New Gerrit change created: https://git.eclipse.org/r/89303

For lack of a test case, this change adds detection of subclass cycles.
- log the unexpected situation
- refuse to record the subclass relation (to avoid the stack overflow)
- does NOT detect indirect cycles.

Comment 7 Eclipse Genie 2017-01-23 03:11:11 EST

Gerrit change https://git.eclipse.org/r/89303 was merged to [master].
Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5b876ff8fddc30314b384e78618ad6f489044c62

Comment 8 John Mu 2017-06-16 15:50:20 EDT

Will this change make it into Oxygen?

Comment 9 John Mu 2017-06-16 15:50:32 EDT

Will this change make it into Oxygen?

Comment 10 Stephan Herrmann 2017-06-16 16:25:35 EDT

(In reply to John Mu from comment #9)
> Will this change make it into Oxygen?

The change discussed in comment 6 has been merged and is part of Oxygen.

The bug remains open, because we haven't yet understood how one could get into the situation and hence the root cause has neither been identifier nor fixed.

Hopefully, the added logging will bring us closer to reproducing the bug.

Comment 11 John Mu 2017-06-16 16:27:22 EDT

I see, thanks for the update. I am on Oxygen RC3 and I still see this bug. 
I'll update if I can find a reliable way to reproduce it. Currently, it seems completely random.

Comment 12 Stephan Herrmann 2017-06-16 17:26:13 EDT

Do you still see the StackOverflowError? Really?

You "should" instead be seeing:

   "Type "+type.getFullyQualifiedName()+" is it's own superclass"

If that doesn't show up, then we're further away from understanding than I thought. Perhaps it's an indirect cycle, i.e., involving several classes...

Comment 13 John Mu 2017-06-16 17:37:15 EDT

I just hit it again.

An internal error occurred during: "Indexing type hierarchy of project ‘foobar’".
java.lang.StackOverflowError

REPORT

anonymousId         d7d66d97-31e1-4b99-a060-53bd73995ca4
name                
email               
comment             
eclipseBuildId      4.7.0.I20170531-2000
eclipseProduct      org.eclipse.epp.package.java.product
javaRuntimeVersion  1.8.0_112-b16
osgiWs              cocoa
osgiOs              MacOSX
osgiOsVersion       10.12.5
osgiArch            x86_64
severity            UNKNOWN


STATUS

pluginId            org.eclipse.core.jobs
pluginVersion       3.9.0.v20170322-0013
code                2
severity            4
message             An internal error occurred during: "Indexing type hierarchy of project ‘foobar’".
fingerprint         60bdabf850dce1a8edef44cf076a1b9b

Exception:java.lang.StackOverflowError: null
	 at java.util.HashMap.hash(HashMap.java:338)
	 at java.util.HashMap.get(HashMap.java:556)
	 at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:507)
	 at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	 at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)

..........

	 at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	 at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	 at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)


BUNDLES

name                org.eclipse.jdt.core
version             3.13.0.v20170516-1929

name                org.eclipse.jdt
version             3.13.0.v20170531-2000

Comment 14 Stephan Herrmann 2018-01-08 15:56:49 EST

We still hope that s.o. can provide a reproducing example. Anyone?

Comment 15 Markus Mitterauer 2018-01-11 09:01:04 EST

Hi, 
unfortunately I cannot provide a reproducable example, but I had this error just three times in a row. Refresh and Cleaning all projects did not help.

From my Error Log (Win 7): 

eclipse.buildId=4.7.2.M20171130-0510
java.version=1.8.0_131
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en
Framework arguments:  -product org.eclipse.epp.package.rcp.product -product org.eclipse.epp.package.rcp.product -product org.eclipse.epp.package.rcp.product -showlocation
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.rcp.product -product org.eclipse.epp.package.rcp.product -product org.eclipse.epp.package.rcp.product -showlocation -clean

This is a continuation of log file C:\<workspace>\.metadata\.bak_0.log
Created Time: 2018-01-11 14:12:23.255

org.eclipse.core.jobs
Error
Thu Jan 11 14:36:02 CET 2018
An internal error occurred during: "Indexing type hierarchy of project ‘foo’".

java.lang.StackOverflowError
	at org.eclipse.jdt.internal.core.PackageFragment.hashCode(PackageFragment.java:421)
	at org.eclipse.jdt.internal.core.AbstractClassFile.hashCode(AbstractClassFile.java:360)
	at org.eclipse.jdt.internal.core.JavaElement.hashCode(JavaElement.java:536)
	at java.util.HashMap.hash(HashMap.java:338)
	at java.util.HashMap.get(HashMap.java:556)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:507)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
        ....

Comment 16 Mike Bratsch 2018-02-07 14:33:29 EST

!SESSION 2018-02-05 12:02:40.865 -----------------------------------------------
eclipse.buildId=4.7.2.M20171130-0510
java.version=1.8.0_112
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -product 
Created Time: 2018-02-06 11:22:01.578

!ENTRY org.eclipse.core.jobs 4 2 2018-02-06 11:22:01.578
!MESSAGE An internal error occurred during: "Indexing type hierarchy of project ‘common’".
!STACK 0
java.lang.StackOverflowError
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:184)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superInterfaces(BinaryTypeBinding.java:1950)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superInterfaces(BinaryTypeBinding.java:1966)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superInterfaces(BinaryTypeBinding.java:1966)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superInterfaces(BinaryTypeBinding.java:1966)
	at

Comment 17 Gert-Jan Boesschen Hospers 2018-04-16 12:32:31 EDT

Created attachment 273630 [details]
On screen error message

I encountered the same error.

Eclipse Java EE IDE for Web Developers.
Version: Oxygen.3a Release (4.7.3a)
Build id: 20180405-1200
OS: Windows 7, v.6.1, x86_64 / win32

!ENTRY org.eclipse.core.jobs 4 2 2018-04-16 17:58:03.629
!MESSAGE An internal error occurred during: "Indexing type hierarchy of project ‘myproject’".
!STACK 0
java.lang.StackOverflowError
	at org.eclipse.jdt.internal.core.JavaElement.hashCode(JavaElement.java:536)
	at java.util.HashMap.hash(Unknown Source)
	at java.util.HashMap.get(Unknown Source)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:507)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:526)

Comment 18 Marcos Pirmez 2018-04-20 09:55:29 EDT

I had this error frequently. Changing the parameters for the JVM in eclipse.ini seems to solve it. I changed the parameters to
-Xms768m
-Xmx5g

Comment 19 Gert-Jan Boesschen Hospers 2018-08-22 07:33:29 EDT

I changed the JVM parameters from -Xms256m -Xmx1024m to -Xms768m -Xmx3g and restarted Eclipse. It didn't help. I still get the StackOverflowError after the change.

Comment 20 Gert-Jan Boesschen Hospers 2018-08-30 08:33:02 EDT

The bug is in the following method of class TypeHierarchy.

private ArrayList<IType> getAllSupertypes0(IType type, ArrayList<IType> supers) {
	IType[] superinterfaces = this.typeToSuperInterfaces.get(type);
	if (superinterfaces == null) // type is not part of the hierarchy
		return supers;
	if (superinterfaces.length != 0) {
		if (supers == null)
			supers = new ArrayList<IType>();
		for (int i1 = 0; i1 < superinterfaces.length; i1++) {
			IType element = superinterfaces[i1];
			if (!supers.contains(element)) {
				supers.add(element);
				supers = getAllSuperInterfaces0(element, supers);
			}
		}
	}
	IType superclass = this.classToSuperclass.get(type);
	if (superclass != null) {
		if (supers == null)
			supers = new ArrayList<>();
		// HERE POTENTIALLY DUPLICATE CLASSES ARE ADDED !!!
		supers.add(superclass);
		supers = getAllSupertypes0(superclass, supers);
	}
	return supers;
}

By adding a check on the existence of superclass in supers, the StackOverflowException does not throw any more. The fixed code:

private ArrayList<IType> getAllSupertypes0(IType type, ArrayList<IType> supers) {
	IType[] superinterfaces = this.typeToSuperInterfaces.get(type);
	if (superinterfaces == null) // type is not part of the hierarchy
		return supers;
	if (superinterfaces.length != 0) {
		if (supers == null)
			supers = new ArrayList<IType>();
		for (int i1 = 0; i1 < superinterfaces.length; i1++) {
			IType element = superinterfaces[i1];
			if (!supers.contains(element)) {
				supers.add(element);
				supers = getAllSuperInterfaces0(element, supers);
			}
		}
	}
	IType superclass = this.classToSuperclass.get(type);
	if (superclass != null) {
		if (supers == null)
			supers = new ArrayList<>();
		// CHECK IF SUPERCLASS ALLREADY IN SUPERS
		if (!supers.contains(superclass)) {
			supers.add(superclass);
			supers = getAllSupertypes0(superclass, supers);
		}
	}
	return supers;
}

The error occured because of the indexing of the following 2 classes in my workspace:
	org.bouncycastle.asn1.ASN1EncodableVector
	org.bouncycastle.asn1.DEREncodableVector
The supers ArrayList was filled with 1000+ entries, like this:
	supers 0: Lorg/bouncycastle/asn1/ASN1EncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.ASN1EncodableVector
	supers 1: Lorg/bouncycastle/asn1/DEREncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.DEREncodableVector
	supers 2: Lorg/bouncycastle/asn1/ASN1EncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.ASN1EncodableVector
	supers 3: Lorg/bouncycastle/asn1/DEREncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.DEREncodableVector
	supers 4: Lorg/bouncycastle/asn1/ASN1EncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.ASN1EncodableVector
	......
	supers 996: Lorg/bouncycastle/asn1/ASN1EncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.ASN1EncodableVector
	supers 997: Lorg/bouncycastle/asn1/DEREncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.DEREncodableVector
	supers 998: Lorg/bouncycastle/asn1/ASN1EncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.ASN1EncodableVector
	supers 999: Lorg/bouncycastle/asn1/DEREncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.DEREncodableVector
	supers 1000: Lorg/bouncycastle/asn1/ASN1EncodableVector;, org.eclipse.jdt.internal.core.ResolvedBinaryType, org.bouncycastle.asn1.ASN1EncodableVector

I do not know how to commit changes to the Eclipse source. I only made a fix for my local environment by creating a new org.eclipse.jdt.core_3.13.102.v20180330-0919.jar and replaced the original jar with my version.

Comment 21 Stephan Herrmann 2018-09-09 12:58:42 EDT

Hi Gert-Jan,

You are on a hot track here.
Still, I'd like to ask you, to dig just a few inches deeper:

(In reply to Gert-Jan Boesschen Hospers from comment #20)
> The bug is in the following method of class TypeHierarchy.
> 
> [...]
> 
> 		// CHECK IF SUPERCLASS ALLREADY IN SUPERS
> 		if (!supers.contains(superclass)) {

If you set a breakpoint with condition "supers.contains(superclass)" what call stack do you see when it suspends at the BP, what's the value of 'type' in each stack frame? Reason for asking: adding the same superclasses over and over looks as if there is a cycle in the superclass chain. 
For superinterfaces duplicates are expected, but for the single superclass chain this probably indicates a bug upstream of this code location as its root cause.

> I do not know how to commit changes to the Eclipse source. 

The canonical way these days is to push a proposed change to gerrit. Here's a comprehensive tutorial: https://www.eclipse.org/community/eclipse_newsletter/2014/july/article3.php
JDT/Core FAQ have a shorter version: https://wiki.eclipse.org/JDT_Core_Committer_FAQ#Releasing_to_gerrit_code_review


Also: doesn't this SO question look exactly like your problem: https://stackoverflow.com/questions/23927880/avoid-cyclic-reference-inheritance-in-grails
So, if the root cause is a configuration problem, then we might be close to creating a regression test. Perhaps, this will also lead us to the optimal code location where the problem can be reported as a proper Error.

Comment 22 Gert-Jan Boesschen Hospers 2018-09-10 08:03:26 EDT

In my project setup I have bcprov-jdk15on-1.51.jar and bcprov-jdk14-1.38.jar in the classpath. This results in a cyclic dependency, according to: https://stackoverflow.com/questions/17584495/unable-to-complete-the-scan-for-annotations-for-web-application-app-due-to-a

On this page it says:
bcprov-jdk15on:1.52 defines DEREncodableVector as public class DEREncodableVector extends ASN1EncodableVector

While bcprov-jdk14:1.38 defines ASN1EncodableVector as public class ASN1EncodableVector extends DEREncodableVector

When the supers.contains(superclass) condition is true, the following data was found:
superclass: org.bouncycastle.asn1.ASN1EncodableVector
supers[0]: org.bouncycastle.asn1.ASN1EncodableVector
supers[1]: org.bouncycastle.asn1.DEREncodableVector

The stacktrace:
java.lang.Exception: supers.contains(superclass)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:543)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:535)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes0(TypeHierarchy.java:535)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getAllSupertypes(TypeHierarchy.java:500)
	at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex.indexType(ProjectTypesIndex.java:410)
	at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex.rebuildRoot(ProjectTypesIndex.java:358)
	at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex.rebuild(ProjectTypesIndex.java:345)
	at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex$2.doRun(ProjectTypesIndex.java:321)
	at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex$2.run(ProjectTypesIndex.java:312)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

Comment 23 Eclipse Genie 2018-10-26 17:32:15 EDT

New Gerrit change created: https://git.eclipse.org/r/131537

Comment 24 Andrey Loskutov 2018-10-26 17:35:11 EDT

(In reply to Eclipse Genie from comment #23)
> New Gerrit change created: https://git.eclipse.org/r/131537

WDYT? Looks simple enough and should fix the current issue independently if we have different other bugs in the type hierarchy computation chain.

Comment 25 Stephan Herrmann 2018-10-27 08:47:10 EDT

(In reply to Andrey Loskutov from comment #24)
> (In reply to Eclipse Genie from comment #23)
> > New Gerrit change created: https://git.eclipse.org/r/131537
> 
> WDYT? Looks simple enough and should fix the current issue independently if
> we have different other bugs in the type hierarchy computation chain.

Looks good. Were you able to reproduce the SOE and observe your change fix it? I would really love to have a test case for this...

Comment 26 Andrey Loskutov 2018-10-27 09:31:32 EDT

(In reply to Stephan Herrmann from comment #25)
> (In reply to Andrey Loskutov from comment #24)
> > (In reply to Eclipse Genie from comment #23)
> > > New Gerrit change created: https://git.eclipse.org/r/131537
> > 
> > WDYT? Looks simple enough and should fix the current issue independently if
> > we have different other bugs in the type hierarchy computation chain.
> 
> Looks good. Were you able to reproduce the SOE and observe your change fix
> it? I would really love to have a test case for this...

Unfortunately no, just read the code & bug here.

Comment 27 Till Brychcy 2018-10-27 09:42:57 EDT

I don't understand how just changing to LinkedHashSet is supposed to fix the problem.

With a LinkedHashSet, a "contains" check in a larger set is cheaper and automatic deduplication is done, but this doesn't stop the recursive invocation in getAllSupertypes0

As the problem is the recursive invocation and the involved sets are very small, I think just doing a contains-check before adding to the ArrayList (and skipping recursive invocation if not adding) will perform better and void duplication as side effect. (LinkedHashSet is a quite expensive data structure)

Comment 28 Andrey Loskutov 2018-10-27 09:43:45 EDT

(In reply to Till Brychcy from comment #27)
> I don't understand how just changing to LinkedHashSet is supposed to fix the
> problem.

Set does not allow duplicates to be added.

Comment 29 Till Brychcy 2018-10-27 09:47:04 EDT

(In reply to Andrey Loskutov from comment #28)
> (In reply to Till Brychcy from comment #27)
> > I don't understand how just changing to LinkedHashSet is supposed to fix the
> > problem.
> 
> Set does not allow duplicates to be added.

Which is not the problem, please read my full comment.

Comment 30 Manoj N Palat 2019-02-11 04:16:24 EST

Bulk move out of 4.11

Comment 31 Andreas Gerasch 2019-07-21 05:50:23 EDT

Hi there,

I'm using eclipse 4.12 and the bug is still there. It is very annoying... any updates here?

Thank you!

Andreas

Comment 32 Manoj N Palat 2019-08-27 01:41:53 EDT

Bulk move to 4.14

Comment 33 Stephan Herrmann 2019-11-17 16:09:19 EST

Bulk move of unassigned bugs to 4.15

Comment 34 Stephan Herrmann 2020-02-27 18:49:22 EST

Bulk move to 4.16

Comment 35 Stephan Herrmann 2020-05-18 18:46:48 EDT

Bulk move of unassigned bugs to 4.17

Comment 36 Eclipse Genie 2022-08-26 12:42:43 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.