Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 445669

Summary:	java.lang.IllegalStateException at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.clone(UnresolvedReferenceBinding.java:43)
Product:	[Eclipse Project] JDT	Reporter:	Tom van den Berge <tom.vandenberge>
Component:	Core	Assignee:	Srikanth Sankaran <srikanth_sankaran>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jarthana, manoj.palat, shankhba, srikanth_sankaran
Version:	4.4
Target Milestone:	4.4.2
Hardware:	PC
OS:	Mac OS X
Whiteboard:

Description Tom van den Berge

2014-10-01 10:24:29 EDT

When compiling classes, I frequently get the error below. 

It happens when the compiled source contains an error (e.g. a syntax error). Unfortunately, I can't isolate a piece of code to reproduce the bug. Maybe it has something to do with the state of my eclipse project.

I'm using 4.4.1 and java 8.


java.lang.IllegalStateException
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.clone(UnresolvedReferenceBinding.java:43)
	at org.eclipse.jdt.internal.compiler.lookup.AnnotatableTypeSystem.getAnnotatedType(AnnotatableTypeSystem.java:339)
	at org.eclipse.jdt.internal.compiler.lookup.AnnotatableTypeSystem.getAnnotatedType(AnnotatableTypeSystem.java:268)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createAnnotatedType(LookupEnvironment.java:989)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.scanFieldForNullAnnotation(BinaryTypeBinding.java:1482)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:493)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:696)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:679)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:299)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:140)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:99)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:180)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:186)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:468)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:522)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:399)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:447)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:763)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:744)

Comment 1 shankha banerjee

2014-10-01 21:14:24 EDT

Bug 445630.

Comment 2 shankha banerjee

2014-10-06 11:45:59 EDT

Hi Tom,
Will it be possible for you to provide us a test case.

Thanks

Comment 3 Tom van den Berge

2014-10-06 16:22:29 EDT

(In reply to shankha banerjee from comment #2)
> Hi Tom,
> Will it be possible for you to provide us a test case.
> 
> Thanks

I can't. I've tried many things, but it seems to have something to do with my project. It's not a specific piece of code that always gives this error.

Comment 4 Srikanth Sankaran

2014-10-07 10:35:52 EDT

(In reply to Tom van den Berge from comment #3)
> (In reply to shankha banerjee from comment #2)
> > Hi Tom,
> > Will it be possible for you to provide us a test case.
> > 
> > Thanks
> 
> I can't. I've tried many things, but it seems to have something to do with
> my project. It's not a specific piece of code that always gives this error.

Tom, did you say you are on 4.4.1 ? I think this is likely the same bug as 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=432977 which was resolved only
for 4.5 M2. If you verify the problem is not there on M2, I can backport the
fix for you.

Comment 5 Tom van den Berge

2014-10-07 15:38:10 EDT

> I think this is likely the same bug as 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=432977 which was resolved only
> for 4.5 M2. 

This bug bug was fixed (or at least it disappeared) in 4.4. Stephan mentions this in comment #9, and I have confirmed the fix in comment #10. I can't reproduce this particular bug in 4.4.1 either.

The bug in question here is unfortunately very hard to reproduce. When I reported it, I could reproduce it in many different classes, but today I can't anymore. Neither the code nor my Eclipse installation have changed. I'm puzzled ;)

Comment 6 Srikanth Sankaran

2014-10-12 22:53:06 EDT

I can readily get rid of this ISE - as it is not strictly speaking a 
correctness issue at the point it is thrown - It is just that the type
system is still holding onto some handles it should not be. Cleanest
would be to understand how that happens and address it, but looks like
without a test case we are not going to be able to do that ....

Comment 7 Srikanth Sankaran

2014-10-13 04:22:32 EDT

OK, I managed to reproduce with a junit.

Sorry, the bug is due to my fault. The throw of IllegalStateException is 
completely unjustified - I was under the impression that once a URB is 
resolved, the resolution propagates itself all over leaving no trace of 
the URB.

I realize now that this is not so. The resolution propagates itself all
over source types yes, but binary types could still be legitimately holding
handles to the URB.

Fix is simply to remove the throw and forward the clone call to the resolved
type.

Fix and tests released here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f316b069838038f8089cd2fbc2dd1992644b54d4.

Comment 8 Srikanth Sankaran

2014-10-13 04:24:37 EDT

Jay, this needs to be backported too.

Comment 9 Jay Arthanareeswaran

2014-10-17 00:53:57 EDT

Reopening for back porting.

Comment 10 Srikanth Sankaran

2014-11-06 05:30:23 EST

In this case, I think you are waiting for the missed out verification during
4.5 M3 ? Anyways updated thw white board content.

Comment 11 Srikanth Sankaran

2014-11-06 21:24:25 EST

Manoj, can you verify this for M3 so Jay can backport this ? TIA

Comment 12 Srikanth Sankaran

2014-11-10 20:24:59 EST

(In reply to Srikanth Sankaran from comment #11)
> Manoj, can you verify this for M3 so Jay can backport this ? TIA

Manoj, can you verify this for M3 so Jay can backport this ? TIA

Comment 13 Srikanth Sankaran

2014-11-11 21:27:52 EST

(In reply to Srikanth Sankaran from comment #12)
> (In reply to Srikanth Sankaran from comment #11)
> > Manoj, can you verify this for M3 so Jay can backport this ? TIA
> 
> Manoj, can you verify this for M3 so Jay can backport this ? TIA

Manoj, can you please verify this so Jay can backport this ? TIA.

Comment 14 Jay Arthanareeswaran

2014-11-11 21:31:44 EST

Verified for 4.5 M3 by code inspection.

Comment 15 Srikanth Sankaran

2014-11-11 23:03:32 EST

(In reply to Jayaprakash Arthanareeswaran from comment #14)
> Verified for 4.5 M3 by code inspection.

Thanks Jay. Now if commit order is not important, I can release this
in the maintenance branch right now - if commit order is important, I suggest 
let us leave this resolved for M3 with whiteboard already tagged for 4.4.2

and

reopen it just in time for backport. (I am not even sure, we need to reopen
to adjust target). Leaving a bug in reopened state for several weeks is 
very unhelpful IMHO. 

Let me know what you would like to do, Thanks Jay.

Comment 16 Jay Arthanareeswaran

2014-11-12 00:38:09 EST

(In reply to Srikanth Sankaran from comment #15)
> Thanks Jay. Now if commit order is not important, I can release this
> in the maintenance branch right now - if commit order is important, I
> suggest 
> let us leave this resolved for M3 with whiteboard already tagged for 4.4.2

It's not important, but in certain cases of M2 candidates, I found dependencies and hence tried the same order. Looks like in this case, there is none, so this can be released already.

> reopen it just in time for backport. (I am not even sure, we need to reopen
> to adjust target). Leaving a bug in reopened state for several weeks is 
> very unhelpful IMHO. 

I understand and I am okay with this. The reason I wanted to do it that way was to differentiate bugs that are being back ported in current batch and bugs that are being considered in future batches. I guess I can just maintain a list locally.

Comment 17 Srikanth Sankaran

2014-11-12 01:37:37 EST

(In reply to Jayaprakash Arthanareeswaran from comment #16)


>Looks like in this case, there
> is none, so this can be released already.

Thanks, released for Luna SR2 here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=R4_4_maintenance&id=38586fcf09747ed185b551296a6070b2be6702ab

Comment 18 Tom van den Berge

2014-11-14 04:09:02 EST

I just upgraded to 4.4.1.M20141112-0800, but I'm still getting the same exception :(

Comment 19 Jay Arthanareeswaran

2014-11-14 04:17:54 EST

(In reply to Tom van den Berge from comment #18)
> I just upgraded to 4.4.1.M20141112-0800, but I'm still getting the same
> exception :(

Sorry to hear that. How did you upgrade? Did you download the full build or through the update site? In any case, can you check what version you have for org.eclipse.jdt.core bundle? Thanks!

Comment 20 Tom van den Berge

2014-11-14 04:50:18 EST

I upgraded through the update site , and I currently have 3.10.0.v20140902-0626 (under Plug-ins), which is not good I guess.

I just updated it again through the update site, and now I have 3.10.2.v20141112-0635. Maybe I did something wrong the first time, but it seems ok now.

I'll let you know if the bug shows up again or not. Thanks!

Comment 21 Jay Arthanareeswaran

2014-11-14 05:04:50 EST

As per comment #20, marking as verified.

Comment 22 Srikanth Sankaran

2014-11-14 05:46:00 EST

(In reply to Tom van den Berge from comment #20)
> I upgraded through the update site , and I currently have
> 3.10.0.v20140902-0626 (under Plug-ins), which is not good I guess.
> 
> I just updated it again through the update site, and now I have
> 3.10.2.v20141112-0635. Maybe I did something wrong the first time, but it
> seems ok now.
> 
> I'll let you know if the bug shows up again or not. Thanks!

Thanks, this particular one cannot show up - it is physically impossible as
UnresolvedReferenceBinding.clone() does not throw ISE any more :)

I am more interested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=445630#c15 since we think it should go away, but have no proof that
it should. 

Thanks Tom.