Community
Participate
Working Groups
Build ID: I20090430-2300 Steps To Reproduce: This happens only in some workspaces, but seems to be dependent on workspace content (starting with fresh workspace and importing leads to same result). Every bundle from target platform is listed twice and entries from PluginRegistry#findEntry have two bundle models with identical location and version. This causes bug 275131.
There's a 'Target Platform State' view. Can you post a screenshot of some duplicates?
Created attachment 135629 [details] Screenshot of duplicate bundles
Bundles are listed only once in target platform view but twice in other views (and bundle selection dialogs), see screenshot. In a particular workspace, every target platform I choose ends with duplicate bundles. I've also observed instances when loading of target platform works correctly, but I can't say what causes this. In other workspaces, everything is OK.
This is rather strange. It seems that in this particular workspace, content of host eclipse platform is added to the target platform, regardless of declared target platform contents. As long as target platform has at least one location declared, running eclipse platform bundles are added to it. This happens most of the time, sometimes target platform is loaded as specified. So, now I see where duplicate bundles come from, but I have no clue how or why eclipse running platform is added to target ...
What locations are specified in your active target definition?
I have different eclipse installs for eclipse target platform location and running platform. But even if I have no eclipse install in my target platform definition, for example jdbc drivers only, I still get eclipse bundles <target name="test"> <locations> <location path="${workspace_loc}/../platform/jdbc/eclipse" type="Directory"/> </locations> <environment> <os>linux</os> <ws>gtk</ws> <arch>x86</arch> <nl>en_US</nl> </environment> <targetJRE path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> </target> Same with absolute path... To complicate things further, it seems that running platform bundles are added to PDE only, not target platform. So running platform bundles are always visible in e.g Open Plugin Artifact view, but not in launch configuration. If I add eclipse target platform to target platform definition, I get duplicate bundles.
Can you screenshot the Target Platform State view? It's a new view as of Eclipse 3.5 M7 :) Are there link files here? ${workspace_loc}/../platform/jdbc/eclipse
Created attachment 135755 [details] Target platform and other views
No link files, just plain directory. It's really strange, since I started from clean workspace and imported projects into it. Well, I imported preferences as well, but I imported exactly same preferences into several other workspaces and they show no such behaviour. I emphasize: same target definitions work OK in other workspaces. So, must be something with this workspace content. Any suggestions where to start debugging ?
After debugging LoadTargetDefinitionJob, it seems that target platform is loaded OK. But dialogs which show duplicate bundles (and launch configuration dialog) get their bundle models from PluginModelManager [1], which stores old bundles. It seems that bundle models are stored PluginModelManager#fEntries, which isn't updated on PluginModelManager#resetState. So old bundles linger on ... [1] PDECore.getDefault().getModelManager()
Incremental update of PluginModelManager#fEntries (or #getEntryTable) in PluginModelManager#resetState seems brittle. Bundles from old target are removed and bundles from new target are added. But if #fEntries ends up in inconsistent/zombie state (maybe from some stored target in .plugins/org.eclipse.pde.core), then zombie plugins will linger there for lifetime of platform and wreak havoc with PDE tooling. So, I would propose clearing #fEntries table or instantiating new PluginModelManager on target platform reload.
After applying this change to HEAD, the zombie bundles are no more and the bug seems fixed. Not sure, however, if this is the right place to reset fEntries table. public class PluginModelManager implements IModelProviderListener { *************** *** 118,123 **** --- 117,124 ---- // reset the state if ((e.getEventTypes() & IModelProviderEvent.TARGET_CHANGED) != 0) { + fEntries = null; + initializeTable(); Object newState = e.getEventSource(); if (newState instanceof PDEState) { fState = (PDEState) newState;
My guess as to why zombie bundles appeared: on problematic workspace, target platform restore on startup somehow didn't work in reliable manner. Or maybe saved state was wrong because of issues like bug 266935. So I had to reload platform on every startup. Target platform state was OK, but PDE state did also include zombie bundles from incomplete restore.
Seems to be solved by patch to 266935. However, I still think that it would be a good idea to clean PluginModelManager#fEntries between target platform reloads.
*** Bug 275131 has been marked as a duplicate of this bug. ***
marking as a dup, since bug 266935 was root cause. *** This bug has been marked as a duplicate of bug 266935 ***
Sorry for wrong report, but I've just noticed duplicate bundles still appear when using patch from bug 266935. So, not a duplicate of bug 266935.
Created attachment 136361 [details] Patch which clears fEntries table This patch seems to work but also needs work, just a working workaround ;)
Seems to be fixed in 3.5RC4, probably because of fix to bug 277611.
Duplicate bundles still appear, reopening.
(In reply to comment #9) > I emphasize: same target definitions work OK in > other workspaces. So, must be something with this workspace content. Is it still true that this is only a problem in one workspace? The target definition you provided in comment#6 shows only one location, but the screen shot in comment#8 looks like it has a target editor with multiple locations. Are there multiple locations?
Yes, only a problem in single workspace, but reproducible from this workspace (and maybe target platform contents). I've rebuilt this workspace from clean slate several times, always leading to this bug (and my patch as only working solution) There are several locations but it also happened when I had single location. But single location was just an example.
In 3.6M2, after manual cleanup of .metadata/.plugins/org.eclipse.pde.core/*.{target,workspace,extensions} and major changes in my workspace and target platform this bug doesn't seem to appear anymore.
This bug still appears, sooner or later. Has something to do with stored platform state (clearing PDE target platform files fixes it temporarily) and reloading, but I don't have time to track it down at present moment. In absence of better solution, I am applying my patch to o.e.pde.core on every milestone release ...
Ok, I think I finally found it, it's a race condition which depends on workspace contents and size. PluginModelManager#initializeTable sometimes calls itself from same thread, so synchronized modifier doesn't order execution. Target platform state is mangled as result( you have two different model objects representing same bundles) which causes many other deeply mysterious bugs. I think one such call sequence begins with fWorkspaceManager.getPluginModels(), which then calls TargetPlatformHelper.getTargetVersionString which then calls PluginModelManager#initializeTable Sample stack trace, note that line numbers in PluginModelManager don't correspond to head, since I have debugging statements in there: java.lang.Exception: Initializing plugin table from thread 31 at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:399) at org.eclipse.pde.internal.core.PluginModelManager.getEntryTable(PluginModelManager.java:385) at org.eclipse.pde.internal.core.PluginModelManager.findEntry(PluginModelManager.java:744) at org.eclipse.pde.internal.core.PluginModelManager.findModel(PluginModelManager.java:768) at org.eclipse.pde.core.plugin.PluginRegistry.findModel(PluginRegistry.java:64) at org.eclipse.pde.internal.core.TargetPlatformHelper.getTargetVersionString(TargetPlatformHelper.java:310) at org.eclipse.pde.internal.core.TargetPlatformHelper.getTargetVersion(TargetPlatformHelper.java:359) at org.eclipse.pde.internal.core.TargetPlatformHelper.getSchemaVersionForTargetVersion(TargetPlatformHelper.java:372) at org.eclipse.pde.internal.core.TargetPlatformHelper.getSchemaVersion(TargetPlatformHelper.java:393) at org.eclipse.pde.internal.core.plugin.PluginHandler.processingInstruction(PluginHandler.java:110) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.processingInstruction(AbstractSAXParser.java:711) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.processingInstruction(XMLDTDValidator.java:1018) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:474) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at javax.xml.parsers.SAXParser.parse(SAXParser.java:198) at org.eclipse.pde.internal.core.plugin.AbstractExtensionsModel.load(AbstractExtensionsModel.java:85) at org.eclipse.pde.internal.core.WorkspaceModelManager.loadModel(WorkspaceModelManager.java:261) at org.eclipse.pde.internal.core.WorkspacePluginModelManager.createModel(WorkspacePluginModelManager.java:73) at org.eclipse.pde.internal.core.WorkspaceModelManager.initialize(WorkspaceModelManager.java:98) at org.eclipse.pde.internal.core.WorkspacePluginModelManager.getPluginModels(WorkspacePluginModelManager.java:349) at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:434) at org.eclipse.pde.internal.core.PluginModelManager.findModel(PluginModelManager.java:782) at org.eclipse.pde.core.plugin.PluginRegistry.findModel(PluginRegistry.java:77) at org.eclipse.pde.internal.core.RequiredPluginsInitializer.initialize(RequiredPluginsInitializer.java:31) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2642) at org.eclipse.jdt.internal.core.JavaModelManager$11.run(JavaModelManager.java:2548) at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2586) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1808) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2667) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2576) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2677) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1864) at org.eclipse.jdt.internal.core.ExternalFoldersManager.refreshReferences(ExternalFoldersManager.java:268) at org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1890) at org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:470) at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.handleEvent(NotificationManager.java:269) at org.eclipse.core.internal.resources.Workspace.broadcastEvent(Workspace.java:319) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1782) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor$3.runInWorkspace(IDEWorkbenchAdvisor.java:373) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Looking at the code, I agree that the synch block might not prevent all race conditions. Will try and look at this. Thanks for taking the time to debug.
Created attachment 154573 [details] My current race condition patch - for demonstration purposes only
Created attachment 228140 [details] Working patch I've been applying this patch for two years. It's the only way to free my main workspace from duplicate bundles. It's not workspace corruption, it's its content :(
FWIW, it finally works at it should in 4.4M4 (but not yet in 4.3.1)
