Community
Participate
Working Groups
Build Identifier: 20100917-0705 The "Problem Occurred" window popped up with the following detail information: An internal error occurred during: "C/C++ Indexer". org.eclipse.core.internal.resources.File cannot be cast to org.eclipse.core.resources.IContainer I have seen no visible trigger for this. The only suspicious thing I can see is that in the "Progress" window the task "Searching for Binaries (My Project)" is running for hours and hours on the same file. But I don't know if this is related to the popup window. Reproducible: Didn't try
Does your log file contain the stack-trace for the exception? <your workspace>/.metadata/.log
Created attachment 181370 [details] Workspace log file containing a stack trace for the exception.
Thanks, the root cause is that IResource.getLocationURI(...) throws the class cast exception: java.lang.ClassCastException: org.eclipse.core.internal.resources.File cannot be cast to org.eclipse.core.resources.IContainer at org.eclipse.core.internal.localstore.FileStoreRoot.getManager(FileStoreRoot.java:66) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:82) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:659) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1132) at org.eclipse.cdt.internal.core.model.CModelManager.createBinaryFile(CModelManager.java:671)
Serge, could you look at it? FileStoreRoot#getManager was introduced along with Dynamic Path Variables.
This is interesting and I've just come across this. It looks like in the view the model is showing an IFile nested within an IFile, and then trying to get the location of the nested file. So at: FileStoreRoot.getManager(IPath) line: 66 workspacePath = /project/Library_Build/libfoo.a/foo.o path = /project/Library_Build/libfoo.a resource = L/project/Library_Build/libfoo.a The path to foo.o is invalid (in the filesystem), so the interesting thing would be whether #getLocationURI should return null or return a location as it does for non-existent files... The API isn't clear on which would be preferred -- and I can think of arguments for both.
Created attachment 182060 [details] fix + test 1 Potential fix + test; simplifies FileStoreRoot#getManager(). Looking at the code, there are three paths through it: 1) If the IResource exists, then #findMember will be none-null and and return resource.getPathVariableManager. 2) If the IResource doesn't exist, but a parent does exist, then the resource is treated as a file, and the path variable manager for that is returned. 3) If a parent doesn't exist, then the WR path variable manager is returned. I believe the second 2 are equivalent, as the ProjectPathVariableManager seems to fall-back to the workspace PathVariableManager when the project can't be found. (Of course if it ever doesn't, then this is likely a bug...) The attached patch therefore simplifies the logic. Returning the resource's PVM if it exists, otherwise a PVM for the resource treated as a WS relative file. Serge what do you think?
Fixed. Thanks James.
