Community
Participate
Working Groups
I'm assuming that CoreModel should never return a null ICProjectDescription for a valid ICProject. I had to put in a workaround in changes I did for bug 151850 because I was getting a null ICProjectDescription from CoreModel when I looked up the active configuration for a project. Without that workaround, some of the UI tests randomly failed. I'm attaching a patch here that detects when a null ICProjectDescription is returned by CoreModel. This will cause some UI tests to randomly fail when AutomatedSuite is run as a whole. When the failed tests are individually run, they pass. Steps to reproduce: 1. Apply attached patch 2. Run AutomatedSuite in the UI plugin
Created attachment 65223 [details] Patch to expose race condition This patch throws an exception when it detects a null ICProjectDescription instead of working around it.
After taking a quick look into the problem it seems that the CProjectDescriptionManager is working correctly. The null project description is returned for the projects that do not really exist. The scenario I'm observing looks like the following: 1. The project "foo" is created in the test "bar". 2. some jobs dealing with the project "foo" are running 3. test "bar" completes, the project "foo" gets deleted 4. BUT there are still some jobs running and referencing the deleted project 5. getProjectDescription is called for the deleted project "foo" -> CoreException Could the UI experts comment on why this could happen? Thanks, Mikhail
(In reply to comment #2) > 5. getProjectDescription is called for the deleted project "foo" -> > CoreException sorry, what I meant to say is that null project description is returned in this case Mikhail
Updating summary and reassigning back to the core inbox for more clarification Below are stack traces explaining the issue. Regards, Mikhail ===Stack trace#1====== Daemon Thread [org.eclipse.cdt.internal.ui.text.CReconciler] (Suspended (breakpoint at line 693 in TranslationUnit)) WorkingCopy(TranslationUnit).getLanguage() line: 693 LanguageManager.getContributedModelBuilderFor(TranslationUnit) line: 291 WorkingCopy(TranslationUnit).parse(Map, IProgressMonitor) line: 598 WorkingCopy(TranslationUnit).buildStructure(OpenableInfo, IProgressMonitor, Map, IResource) line: 397 WorkingCopy(Openable).generateInfos(Object, Map, IProgressMonitor) line: 260 WorkingCopy(CElement).openWhenClosed(CElementInfo, IProgressMonitor) line: 394 WorkingCopy(CElement).getElementInfo(IProgressMonitor) line: 274 WorkingCopy(TranslationUnit).getElementInfo(IProgressMonitor) line: 385 WorkingCopy(CElement).getElementInfo() line: 264 WorkingCopy(Openable).getBuffer() line: 109 WorkingCopy(TranslationUnit).getContents() line: 415 WorkingCopy(TranslationUnit).getCodeReader() line: 818 WorkingCopy(TranslationUnit).getAST(IIndex, int) line: 759 ASTCache$1.run() line: 276 SafeRunner.run(ISafeRunnable) line: 37 ASTCache.createAST(ITranslationUnit, IIndex, IProgressMonitor) line: 270 ASTProvider.createAST(ICElement, IIndex, IProgressMonitor) line: 340 CEditor.reconciled(boolean) line: 2510 CReconcilingStrategy.reconcile(boolean) line: 160 CReconcilingStrategy.initialReconcile() line: 169 CReconciler(MonoReconciler).initialProcess() line: 103 AbstractReconciler$BackgroundThread.run() line: 170 ====Stack trace#2===== Daemon Thread [org.eclipse.cdt.internal.ui.text.CReconciler] (Suspended (breakpoint at line 693 in TranslationUnit)) WorkingCopy(TranslationUnit).getLanguage() line: 693 WorkingCopy(TranslationUnit).getAST(IIndex, int) line: 762 ASTCache$1.run() line: 276 SafeRunner.run(ISafeRunnable) line: 37 ASTCache.createAST(ITranslationUnit, IIndex, IProgressMonitor) line: 270 ASTProvider.createAST(ICElement, IIndex, IProgressMonitor) line: 340 CEditor.reconciled(boolean) line: 2510 CReconcilingStrategy.reconcile(boolean) line: 160 CReconcilingStrategy.initialReconcile() line: 169 CReconciler(MonoReconciler).initialProcess() line: 103 AbstractReconciler$BackgroundThread.run() line: 170
Thanks for looking into this, Mikhail! The reconciler (where the null ICProjectDescription is being returned) runs in a separate thread and periodically updates the model based on changes in the editor. It looks like the reconciler is still being activated for a TranslationUnit whose parent IProject has already been deleted. I'll investigate further.
The problem is that tests that open editors need to close them all before deleting the project(s). This should be part of the test's tearDown method. Eclipse editors are not meant to close themselves when resources are no longer accessible. I'll fix those tests that appear to fail with the patch of comment 1 applied.
Fixed the failing tests of AutomatedSuite.
