Community
Participate
Working Groups
Created attachment 236178 [details] Zipped up workspace containing the two projects This is a new workspace with just the minimal two projects that can be used to demonstrate the bug.
Created attachment 236179 [details] Screenshot of error message
Created attachment 236180 [details] Screenshot of Eclipse version info
I have found what I think is a bug with Eclipse (version 4.3.1) I repeatedly find content assists and code completion will break under the following conditions. 1. Create a new project (mine was called StringComparator) with a singe Java file called TestProjectInclude.java containing the following java code) -------------------------------------------- import java.util.Comparator; public class TestProjectInclude { } class OrderedStringComparator1 implements Comparator<String> { @Override public int compare(String s1, String s2) { return 0; } } class OrderedStringComparator2 implements Comparator<String> { @Override public int compare(String s1, String s2) { return 0; } } class OrderedStringComparator3 implements Comparator<String> { @Override public int compare(String s1, String s2) { return 0; } } class OrderedStringComparator4 implements Comparator<String> { @Override public int compare(String s1, String s2) { return 0; } } -------------------------------------------- Create a new project (mine was called TestProject with a single java file -------------------------------------------- public class TestClass { int f; public static void main(String[] args) { TestClass tc = new TestClass(); tc.f = 3; } } -------------------------------------------- This second project at first will work fine and content assist is working. Now add the StringComparator project to the TestProject's build path. Close and re-open the TestProject. Content assist is now broken for TestProject An attempt to use it results in the following error: java.lang.ClassCastException: org.eclipse.jdt.internal.core.SourceType cannot be cast to java.lang.String at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesSearching(JavaModelManager.java:4579) at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypes(JavaModelManager.java:4438) 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:145) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getType(PackageBinding.java:141) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.isViewedAsDeprecated(PackageBinding.java:225) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isViewedAsDeprecated(ReferenceBinding.java:1416) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:378) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:700) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:676) at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:298) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:151) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1179) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getResolvedType(LookupEnvironment.java:1115) at org.eclipse.jdt.internal.compiler.lookup.Scope.getJavaLangObject(Scope.java:2352) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:907) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1065) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:304) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:214) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:746) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:383) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1133) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:685) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807) 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) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) ------------------ eclipse.buildId=4.3.0.M20130911-1000 java.version=1.8.0-ea java.vendor=Oracle Corporation BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -product org.eclipse.epp.package.standard.product -keyring /Users/michaelellis/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.standard.product -keyring /Users/michaelellis/.eclipse_keyring -showlocation
We have multiple reports of this. The CCE is indicative of basic mess up somewhere. Anirban, please fix this for M3.
(In reply to Srikanth Sankaran from comment #5) > We have multiple reports of this. The CCE is indicative of basic mess up > somewhere. Anirban, please fix this for M3. This issue is seen at BETA_JAVA8 as well. There is a concurrency issue here as follows: The iterator is being used to iterate loop, while the entry is being replaced - though its just a replacement, in some cases, internally this causes a resize, which results in pointer corruption from iterator's point of view, which in turn retrieves an already replaced entry (the value of which would now be of type SourceType) resulting in the error reported.
(In reply to Manoj Palat from comment #6) > (In reply to Srikanth Sankaran from comment #5) > > We have multiple reports of this. The CCE is indicative of basic mess up > > somewhere. Anirban, please fix this for M3. > > This issue is seen at BETA_JAVA8 as well. There is a concurrency issue here > as follows: > The iterator is being used to iterate loop, while the entry is being > replaced - though its just a replacement, in some cases, internally this > causes a resize, which results in pointer corruption from iterator's point > of view, which in turn retrieves an already replaced entry (the value of > which would now be of type SourceType) resulting in the error reported. Thanks for the analysis Manoj. Anirban, please work with Jay on this since he knows the Java model well to figure out what the suitable synchronization primitives should be.
I recently ran into this, which I recorded at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=420041#c4 Unfortunately I can no longer reproduce this. But at that point, I strongly believed (still do), that this was an issue with JRE 8 (I used b108). Michael, could you do a small experiment with a JRE7 or lower and see if you still see the bug?
The problem still exists when using Java 7 Java version = 1.7.0_25 I'm running on Apple MacBook Retina
(In reply to Michael Ellis from comment #4) > I have found what I think is a bug with Eclipse (version 4.3.1) Anirban, I can reproduce the bug with the given testcase. I believe you need to have the annotation based null analysis enabled at the global preferences. Could you give it a try?
(In reply to Jayaprakash Arthanareeswaran from comment #10) > (In reply to Michael Ellis from comment #4) > > I have found what I think is a bug with Eclipse (version 4.3.1) > > > Anirban, I can reproduce the bug with the given testcase. I believe you need > to have the annotation based null analysis enabled at the global > preferences. Could you give it a try? As I observed in bug 420041, the key is having secondary type, which means the HashTable contains same path with different type names as keys.
Created attachment 236995 [details] Code patch Hello, Thanks to Manoj and Jay for help while solving this bug. The problem is due to the fact that an underlying collection is constantly getting changed while the iterator is walking. The documentation clearly mentions that HashMap-iterator.remove() does not allow changing the container in any other way. Like many other memory errors, this shows up inconsistently. I'm posting the solution patch, which has passed regression. I'm working on the junit testcase, with help of Jay, where it seems difficult to hit the scenario. Thanks Anirban
Created attachment 237032 [details] Code patch after review comments Uploading code patch after review comments. Yet to come up with a junit testcase.
Thanks Anirban, I have released the fix with a couple of minor changes: 1. tempTypes.clear() is redundant as tempTypes itself go out of scope. 2. Removed the redundant comment. http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=76962ee0c50a3b7551973355aa71fa2a5e76ae6b Manoj, I believe you have seen the patch already. In any case, I encourage you to look at the final commit and update the review flag. Thanks!
(In reply to Jayaprakash Arthanareeswaran from comment #14) > Thanks Anirban, I have released the fix with a couple of minor changes: > Manoj, I believe you have seen the patch already. In any case, I encourage > you to look at the final commit and update the review flag. Thanks! Yes Jay. +1 from my review.
Verified for version 4.4 M3 Build id: I20131029-2000
Can someone tell me how I can get this fix. Is there a new version of Eclipse or some update mechanism. This bug is driving me spare! Thanks for any help.
(In reply to Michael Ellis from comment #17) > Can someone tell me how I can get this fix. Is there a new version of > Eclipse or some update mechanism. This bug is driving me spare! > > Thanks for any help. You can update to the latest I build via this update site: http://download.eclipse.org/eclipse/updates/4.4-I-builds
Ah. Sorry to waste anyone's time. Worked it out. Downloaded 4.4M3 from http://download.eclipse.org/eclipse/downloads/drops4/S-4.4M3-201310302000/ (In reply to Jayaprakash Arthanareeswaran from comment #18) > (In reply to Michael Ellis from comment #17) > > Can someone tell me how I can get this fix. Is there a new version of > > Eclipse or some update mechanism. This bug is driving me spare! > > > > Thanks for any help. > > You can update to the latest I build via this update site: > > http://download.eclipse.org/eclipse/updates/4.4-I-builds
