Community
Participate
Working Groups
Currently, when you create a new project and the per-project scanner discovery gets kicked off, the IDE complains about the scheduling rule used by the xlc collector to update the info in the job it kicks off. It should block on the workspace root instead of the project, as some project description updates still seem to want to grab the workspace root. Here was the stack trace: org.eclipse.core.runtime.CoreException: Attempted to beginRule: R/, does not match outer scope rule: P/test_8_0 at org.eclipse.cdt.internal.core.settings.model.ExceptionFactory.createCoreException(ExceptionFactory.java:26) at org.eclipse.cdt.internal.core.settings.model.AbstractCProjectDescriptionStorage.setProjectDescription(AbstractCProjectDescriptionStorage.java:205) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionStorageManager.setProjectDescription(CProjectDescriptionStorageManager.java:147) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.setProjectDescription(CProjectDescriptionManager.java:836) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.setProjectDescription(CProjectDescriptionManager.java:806) at org.eclipse.cdt.make.xlc.core.scannerconfig.PerFileXLCScannerInfoCollector$ScannerConfigUpdateJob.run(PerFileXLCScannerInfoCollector.java:166) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: P/test_8_0 at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:136) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:326) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:85) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:285) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:117) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1914) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1970) at org.eclipse.cdt.internal.core.model.CModelOperation.runOperation(CModelOperation.java:635) at org.eclipse.cdt.internal.core.settings.model.AbstractCProjectDescriptionStorage.setProjectDescription(AbstractCProjectDescriptionStorage.java:203) ... 5 more
Created attachment 170566 [details] patch Attached a proposed patch.
I'm going to try this at home just to make sure of no weird deadlock issues. In the meantime, if you guys would be willing to review it and let me know your thoughts, I'd appreciate it.
Yes, this is an issue. When fiddling with the project description stuff I tried to reduce the sched rule scope to the project, but this broke a bunch of indexer tests which assert that the WR rule is held during set. I filed bug 278636 for this. Using the WR rule is ok here. The alternative is to use an ILock if you're just trying to prevent concurrent running of your ScannerConfigUpdateJob. The WR is safer however if you're get()ing and set()ing the projdesc as it looks like you're trying to do. If this is ok performance-wise I'd do this for the moment and optimize it later.
No deadlocks that I can find... Committed to HEAD.
*** cdt cvs genie on behalf of crecoskie *** Bug 315117 - xlc scanner discovery scheduling rule issue [*] PerFileXLCScannerInfoCollector.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/xlc/org.eclipse.cdt.make.xlc.core/src/org/eclipse/cdt/make/xlc/core/scannerconfig/PerFileXLCScannerInfoCollector.java?root=Tools_Project&r1=1.3&r2=1.4 [*] MANIFEST.MF 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/xlc/org.eclipse.cdt.make.xlc.core/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.5&r2=1.6
Acknowledge review flag, committed some time ago.
