Community
Participate
Working Groups
I20120607-1500 (4.2 RC4 candidate) Found this log entry shortly after starting up the first time with said build: Error Fri Jun 08 12:08:36 CEST 2012 Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.core.internal.events.BuildCommand.addBuilder(BuildCommand.java:253) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:539) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:567) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:237) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Got the same exception on Mac Cocoa x86_64 right after updating to I20120608-1200 (3.8 RC4). Also couldn't reproduce.
This time, I got the exception in the runtime workbench. It tried to add an "ApiAnalysisBuilder" to the "org.eclipse.core.databinding" project. I can't prove a connection, but I think this always happened shortly after I installed the "API Tools Execution Environment Descriptions".
eclipse.buildId=4.3.0.I20130430-0031 Cocoa x86_64 java.version=1.7.0_21 Got this again. I installed the "API Tools Execution Environment Descriptions", restarted Eclipse, and then selected 2 outdated compile errors in the Problems view and cleaned the affected projects. org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.core.internal.events.BuildCommand.addBuilder(BuildCommand.java:249) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:539) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:567) at org.eclipse.core.internal.events.BuildManager.getRule(BuildManager.java:1110) at org.eclipse.core.internal.resources.Project$1.run(Project.java:612) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2345) at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:597) at org.eclipse.core.internal.resources.Project.build(Project.java:114) at org.eclipse.ui.internal.ide.dialogs.CleanDialog.doClean(CleanDialog.java:319) at org.eclipse.ui.internal.ide.dialogs.CleanDialog$1.runInWorkspace(CleanDialog.java:151) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Seen the same assertion when launching 4.3RC1 standard/SDK EPP package first time on Linux x86_64 with Oracle 1.7.0_21 JVM. I had opened an existing workspace which I had prepared the same day with Eclipse Platform SDK on the same host but 32-bit Eclipse on Oracle 1.6.0_43 JVM. eclipse.buildId=4.3.0.I20130516-2200 java.version=1.7.0_21 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.classic.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.classic.product org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.core.internal.events.BuildCommand.addBuilder(BuildCommand.java:249) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:539) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:567) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:237) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Seen the issue again (Eclipse 4.3rc1, Ubuntu 12.04_64bit, Oracle Java7). This time when Eclipse restarted after installing the Releng.Tools add-on. But it's not reproducible - Eclipse also started without message a couple times.
Happened again on I20130709-0800: !ENTRY org.eclipse.core.resources 4 2 2013-07-16 15:35:58.359 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.core.internal.events.BuildCommand.addBuilder(BuildCommand.java:249) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:539) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:567) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:237) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:514) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:423) at org.eclipse.ui.internal.ide.dialogs.CleanDialog.doClean(CleanDialog.java:313) at org.eclipse.ui.internal.ide.dialogs.CleanDialog$1.runInWorkspace(CleanDialog.java:151) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) !ENTRY org.eclipse.core.resources 2 75 2013-07-16 15:36:02.203 !MESSAGE Errors occurred during the build. !SUBENTRY 1 org.eclipse.core.resources 2 566 2013-07-16 15:36:02.203 !MESSAGE assertion failed: !STACK 0 org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.core.internal.events.BuildCommand.addBuilder(BuildCommand.java:249) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:539) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:567) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:237) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:514) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:423) at org.eclipse.ui.internal.ide.dialogs.CleanDialog.doClean(CleanDialog.java:313) at org.eclipse.ui.internal.ide.dialogs.CleanDialog$1.runInWorkspace(CleanDialog.java:151) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Happened again in: Version: 4.4.0 Build id: I20130806-0800
The bug is in API Tools, see stack trace below. During a clean, API Tools gets loaded and if the EE descriptions changed, it will issue a full rebuild during the original clean request. This leaves the build command in a weird state. Thread [Worker-2] (Suspended) BuildManager.getBuilder(IBuildConfiguration, ICommand, int, MultiStatus) line: 559 BuildManager.getRule(IBuildConfiguration, int, String, Map<String,String>) line: 1148 Project$1.run(IProgressMonitor) line: 612 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2333 Project.internalBuild(IBuildConfiguration, int, String, Map<String,String>, IProgressMonitor) line: 597 Project.build(int, String, Map<String,String>, IProgressMonitor) line: 124 ApiPlugin.checkForEEDescriptionChanges() line: 674 ApiPlugin.start(BundleContext) line: 604 BundleContextImpl$3.run() line: 771 BundleContextImpl$3.run() line: 1 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method] BundleContextImpl.startActivator(BundleActivator) line: 764 BundleContextImpl.start() line: 721 EquinoxBundle.startWorker0() line: 936 EquinoxBundle$EquinoxModule.startWorker() line: 319 EquinoxBundle$EquinoxModule(Module).doStart(Module$StartOptions...) line: 567 EquinoxBundle$EquinoxModule(Module).start(Module$StartOptions...) line: 438 SecureAction.start(Module, Module$StartOptions...) line: 454 EclipseLazyStarter.postFindLocalClass(String, Class<?>, ClasspathManager) line: 107 ClasspathManager.findLocalClass(String) line: 531 EquinoxClassLoader(ModuleClassLoader).findLocalClass(String) line: 330 BundleLoader.findLocalClass(String) line: 311 BundleLoader.findClassInternal(String, boolean) line: 379 BundleLoader.findClass(String, boolean) line: 336 BundleLoader.findClass(String) line: 328 EquinoxClassLoader(ModuleClassLoader).loadClass(String, boolean) line: 160 EquinoxClassLoader(ClassLoader).loadClass(String) line: 356 EquinoxBundle.loadClass(String) line: 568 EquinoxRegistryStrategy(RegistryStrategyOSGI).createExecutableExtension(RegistryContributor, String, String) line: 174 ExtensionRegistry.createExecutableExtension(RegistryContributor, String, String) line: 905 ConfigurationElement.createExecutableExtension(String) line: 243 ConfigurationElementHandle.createExecutableExtension(String) line: 55 BuildManager.instantiateBuilder(String) line: 907 BuildManager.initializeBuilder(String, IBuildConfiguration, int, MultiStatus) line: 860 BuildManager.getBuilder(IBuildConfiguration, ICommand, int, MultiStatus) line: 545 BuildManager.getBuilder(IBuildConfiguration, ICommand, int, MultiStatus, IBuildContext) line: 574 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 244 BuildManager$1.run() line: 299 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 302 BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 358 BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 381 Workspace.buildInternal(IBuildConfiguration[], int, boolean, IProgressMonitor) line: 516 Workspace.build(int, IProgressMonitor) line: 425 CleanDialog.doClean(boolean, IProgressMonitor) line: 318 CleanDialog$1.runInWorkspace(IProgressMonitor) line: 151 CleanDialog$1(InternalWorkspaceJob).run(IProgressMonitor) line: 38 Worker.run() line: 53
Test case: 1. create a plug-in project and enable API Tools 2. on 'API Errors/Warnings, set 'Reference not defined in specified execution environment' to 'Ignore' ==> error on project about missing EE descriptions 2. install EEs 3. restart ==> error stays (bug 431792) 4. Clean and rebuild ==> exception
This bug appears to be the cause of the test custom environment test failures (Bug 421581).
Moving to 4.5M3
Moving to 4.5M4
This problem is caused by changes for Bug 361660. As mentioned previously, this is caused because API tools is loaded during clean and API tools ApiPlugin::checkForEEDescriptionChanges() is called and there are changes in EEDescriptionChanges. So either ApiPlugin::checkForEEDescriptionChanges() should be called during buildAll or API tools should be loaded where an eclipse is launched with a workspace with at least 1 plugin project. Putting Platform.getPlugin("org.eclipse.pde.api.tools"); in PDEPlugin::start function would ensure that API tools is loaded but this looks more like a hack. Also this would fix Bug 356394 also. I also checked that removing checkForEEDescriptionChanges() does work ok. I expected some scenario of Bug 361660 to not work but I was unable to do so. ( may be I missed some steps). So options here are 1) use some form of code to ensure api tools gets loaded 2) move checkForEEDescriptionChanges code to rebuild all location.
Created attachment 249232 [details] Forcing load of api tools in pde.ui Forcing load of api tools in pde.ui to ensure EEDescriptionChanges are incorporated
(In reply to Vikas Chandra from comment #14) > Created attachment 249232 [details] > Forcing load of api tools in pde.ui > > Forcing load of api tools in pde.ui to ensure EEDescriptionChanges are > incorporated We do not want API Tools to be forced to start anytime you have a plug-in project. The PDE model init already slows down startup more than we want. This change would also force start API Tools even if I don't have it enabled on any project.
Thanks Curtis. So, I think checkForEEDescriptionChanges should be moved out of plugin load or should be scheduled till after clean operation is finished. I plan to have something for this in early 4.5M5
Created attachment 250010 [details] Fix I've moved checkForEEDescriptionChanges() to ApiAnalysisBuilder::build. Forcing api tool load and schedule of checkForEEDescriptionChanges was not a viable option. So as previously stated, I think checkForEEDescriptionChanges() should move to the first call of ApiAnalysisBuilder::build
I don't have time for a proper review right now, perhaps Dani or Markus can give it some attention. However, just reviewing the patch I have a couple concerns: 1) If multiple projects had to be built, couldn't this result in the code to check ee changes running multiple times. The boolean flag is changed after the ee changes are checked, so even if a second project is build after the first, the code could be executed multiple times. 2) Similarly, if ee changes are found and a full build is kicked off from the change check, couldn't it then also start another ee change check itself? 3) This might be defeating the original purpose of the ee change check during plug-in load. Now we will only recognize EE changes if a project is touched. So the user has a built workspace, they install the EE descriptions, restart and now they have the exact same build state. Only when they touch a project do all the relevant projects gets rebuilt with the new EE information. To deal with 3, could we still do the pref check during plug-in load, but touch one or more projects. Then when the build happens for the projects we could do a full clean/rebuild cycle.
Created attachment 250074 [details] Updated Fix.
1) Since buildEEDecriptorChanges is static, it will be initialised only once. It will be called only once for multiple projects. 2) I have put a synchronized block so that it is not called simultaneously for multiple projects. 3) checkForEEDescriptionChanges() should be called only once during the 1st time build of first project of APIAnalysisBuilder. It will be called multiple times if launched to multiple instances in which case I think this should be called at each new startup.
(In reply to Vikas Chandra from comment #20) > 1) Since buildEEDecriptorChanges is static, it will be initialised only > once. It will be called only once for multiple projects. > 2) I have put a synchronized block so that it is not called simultaneously > for multiple projects. > 3) checkForEEDescriptionChanges() should be called only once during the 1st > time build of first project of APIAnalysisBuilder. I'm still concerned that by making this part of the build it could end up looping back into checking ee changes more than once. I will have to run the patch to do a full review. Adding synchronize blocks to a build is also high risk.
Review is pending. Moving it to M6 .
(In reply to Curtis Windatt from comment #21) > Adding synchronize blocks to a build is also > high risk. +1. We should try to avoid this.
Then my view is that we should consider patch in comment#17. And if we are to push in this fix, it must be done early in M6 and not near the cut-off date.
I just ran into this with "Eclipse for Committers Oxygen M6". Imported 3 plug-in projects into an existing workspace, the Error Reporting told me that I had run into this known bug. Any plans fixing this ?
Here is the Oxygen backtrace: org.eclipse.core.runtime.AssertionFailedException: assertion failed: Current builder: org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder, new builder: org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder, configuration: org.eclipse.tcf.core; [] at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.internal.events.BuildCommand.addBuilder(BuildCommand.java:244) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:551) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:576) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:244) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Is your steps same as comment#9 or do you get during a different step?
(In reply to Vikas Chandra from comment #27) > Is your steps same as comment#9 or do you get during a different step? No, my steps are very different. As per comment #25: Given an existing workspace that compiles cleanly, I just imported 3 new plug-in projects.
I think we've fixed this in 4.8 via bug 517411. I was not aware that this one exists. Feel free to reopen if still reproducible. *** This bug has been marked as a duplicate of bug 517411 ***
