Bugzilla – Full Text Bug Listing
| Summary: | Classcast exception when commenting code referenced by another file | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Samantha Chan <chanskw> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sebastian.zarnekow, sven.efftinge |
| Version: | 1.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Samantha Chan
I think this is a race condition. When the exception happens, the validator / builder state tries to resolve all references. It was able to resolve references successfully to the correct EObjectDescription. When I look at the EObjectDescription, its fragment field is linked to the old location in the file. After this processing is done, the following happens to update the fragments in the EObjectDescription: Thread [Worker-21] (Suspended (breakpoint at line 160 in EObjectDescriptionImpl)) owns: PersistableResourceDescriptionsImpl (id=4897) EObjectDescriptionImpl.setFragment(String) line: 160 BuilderStateUtil.create(IEObjectDescription) line: 61 BuilderStateUtil.create(IResourceDescription) line: 31 PersistableResourceDescriptionsImpl.createNew(Delta, Set<URI>) line: 84 PersistableResourceDescriptionsImpl.doUpdate(ResourceSet, Set<URI>, Set<URI>, Map<URI,IResourceDescription>, IProgressMonitor) line: 60 PersistableResourceDescriptionsImpl.doUpdate(ResourceSet, Set, Set, Map, IProgressMonitor) line: 1 PersistableResourceDescriptionsImpl(AbstractBuilderState).update(ResourceSet, Set<URI>, Set<URI>, IProgressMonitor) line: 111 XtextBuilder.doBuild(ToBeBuilt, IProgressMonitor, IXtextBuilderParticipant$BuildType) line: 148 XtextBuilder.incrementalBuild(IResourceDelta, IProgressMonitor) line: 133 XtextBuilder.build(int, Map, IProgressMonitor) line: 86 BuildManager$2.run() line: 629 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, MultiStatus, IProgressMonitor) line: 172 BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, IProgressMonitor) line: 203 BuildManager$1.run() line: 255 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) line: 258 BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, IProgressMonitor) line: 311 BuildManager.build(int, IProgressMonitor) line: 343 AutoBuildJob.doBuild(IProgressMonitor) line: 144 AutoBuildJob.run(IProgressMonitor) line: 242 Worker.run() line: 54 It seems to me that the order of this is incorrect. Shouldn't the builder be run first, update the fragment, and then do the validation ? Please let me know if you need additional information to debug this. Perhaps I am wrong... I am also seeing that all these things can be run at the same time, or the fragement can get updated before the validation jobs. But I still get into this class cast exception because the fragment is pointing to the old location. What kind of customizations have you done? (In reply to comment #3) > What kind of customizations have you done? I have customized the local scope provider, where I have caching implemented. I commented out my caching code, and still saw this exception. I also have a custom global scope provider. In there, I have customized the #createContainerScopeWithContext... where I provided my own FilterUriContainer to get around a NPE that I previously reported. In the global scope provider, I have also customized it such that it will look for content from an external index if the element is not found in in the resource descriptions. Hi Samantha, please make sure that your FilterUriContainer works as expected. Its original implementation was introduced to avoid these CCEs. (In reply to comment #5) > Hi Samantha, > > please make sure that your FilterUriContainer works as expected. Its original > implementation was introduced to avoid these CCEs. Hello, I backed out the changed for the customized FilterUriContainer, and still experienced the same problem with the default implementation. I am not sure I understand the use of the FilterUriContainer very well, to determine if that is causing problems... or how to look for things that may cause problems. Can you provide some insight as to go about debugging this? Thanks... Samantha Samantha, is this one still an issue for you? Ping (and lowering the severity) closing this, because there was no feedback. |