Community
Participate
Working Groups
Build Identifier: 20110916-0149 Running "eclipse -clean" gives an endless loop pretty much as described in bug 235006. Nothing is written to .metadata/.log. The system starts up fine w/o "-clean" command line parameter. Guess it has to do with a plugin, but at this time, I don't know how to track that down. Reproducible: Always Steps to Reproduce: 1. eclipse -clean
Do you have any additional information? What bundles do you have installed, how did you install them etc?
Created attachment 208000 [details] eclipse configuration Attached eclipse configuraiton - sorry for the inconvenience. Please let me know if you need further information.
Sorry, forgot to mention that the vast majority of extensions have been installed via eclipse marketplace. A few via update sites manually added. No extensions have been installed in the dropins folder.
(In reply to comment #2) > Created attachment 208000 [details] > eclipse configuration > > Attached eclipse configuraiton - sorry for the inconvenience. > > Please let me know if you need further information. thanks this is helpful. It points out that you have two org.codehaus.groovy.frameworkadapter framework extension bundles installed: Id: org.codehaus.groovy.frameworkadapter, Version: 2.5.2.xx-20110921-1600-e37, Location: reference:file:plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110921-1600-e37.jar Id: org.codehaus.groovy.frameworkadapter, Version: 2.5.2.xx-20110929-1800-e37, Location: initial@reference:file:plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110929-1800-e37.jar/ I am not sure why that old version is hanging around. I suspect p2 may be trying to uninstall it and causing a refresh cycle. Can you also attach the bundles.info for your installation? It should be in your configuration folder under configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
Created attachment 208054 [details] bundles.info
Andreas, if you could give me steps for what you installed from market place it would really help me figure out what is going wrong here. Also, how did you get a hold of the eclipse configuration if eclipse was in an infinite loop? Did you get that configuration before running with -clean?
I think I understand more about what is going on. I suspect the relaunch is continually passing -clean in and p2 is installing another version of the org.codehaus.groovy.frameworkadapter and calling refresh. Because in equinox a refresh of a bundle which has other versions (with same symbolic name) pulls in all versions to the refresh this ultimately causes the framework extension to be pulled in which is currently attached to the system bundle. This causes a restart, but since -clean was passed in we start all over again, and again. Instead of passing -clean you probably can try simply deleting the configuration/org.eclipse.osgi folder (which is basically what -clean does).
Thomas, its really hard to tell now which bundles got installed via marketplace and which directly via update site. I'd guess that more than 90% got installed via market place. Removed configuration/org.eclipse.osgi manually and subsequent start (eclipse w/o -clean works fine). Exiting and then executing "eclipse -clean" again makes it still enter the infinite loop. And indeed, every java process started gets -clean passed. The full command line reads: /usr/bin/java -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=384m -XX:ReservedCodeCacheSize=64m -Xms40m -Xmx1024m -jar /opt/eclipse-3.7//plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /opt/eclipse-3.7/eclipse -name Eclipse --launcher.library /opt/eclipse-3.7//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.100.v20110505/eclipse_1407.so -startup /opt/eclipse-3.7//plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar --launcher.overrideVmargs -exitdata 10aa0046 -product org.eclipse.epp.package.jee.product -clean -vm /usr/bin/java -vmargs -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=384m -XX:ReservedCodeCacheSize=64m -Xms40m -Xmx1024m -jar /opt/eclipse-3.7//plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
Thanks Andreas, I think I understand now what is going on. I think we have had a bug similar to this in the past. Here are two ways to consider for solving this: 1) When performing a restart remove the -clean option so we don't continually wipe the configuration area clean. This is probably good to consider but I think it is more of a work around to the real issue. 2) When refreshing bundles we should probably avoid pulling in system bundle fragments (framework extensions) when refreshing another bundle with the same symbolic name. This is somewhat related to bug351519. We added an option to disable automatically pulling in bundles with the same symbolic name (using config option equinox.refresh.duplicate.bsn=false). We should probably never auto pull in system bundle fragments. Another option is to default equinox.refresh.duplicate.bsn=true for juno, which is not a bad idea either. Andreas, could you try setting "equinox.refresh.duplicate.bsn=false" in your config.ini and trying -clean option again to confirm my theory. Thanks for your assistance.
(In reply to comment #9) > Another option is to default > equinox.refresh.duplicate.bsn=true for juno, which is not a bad idea either. > I meant to default equinox.refresh.duplicate.bsn=false for juno.
equinox.refresh.duplicate.bsn=false in config.ini solves the problem. "eclipse -clean" works fine now. Is that option safe to keep ? Which bundle is triggering the infinite loop ?
*** Bug 368184 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > equinox.refresh.duplicate.bsn=false in config.ini solves the problem. "eclipse > -clean" works fine now. > > Is that option safe to keep ? > > Which bundle is triggering the infinite loop ? The installation of org.codehaus.groovy.frameworkadapter is causing this infinite loop. It is not because of an issue with the bundle org.codehaus.groovy.frameworkadapter directly, but because p2 thinks multiple versions of the bundle should be installed. When running with -clean the framework boots up and load one version of the org.codehaus.groovy.frameworkadapter framework extensions. Then p2 kicks in and decides to install another version of org.codehaus.groovy.frameworkadapter and calls refresh. Since equinox.refresh.duplicate.bsn=true by default the framework will force the version of org.codehaus.groovy.frameworkadapter used as an extension by the framework to be refreshed also which cases the framework to restart again with -clean so the whole process starts over again and again.
(In reply to comment #11) > equinox.refresh.duplicate.bsn=false in config.ini solves the problem. "eclipse > -clean" works fine now. > > Is that option safe to keep ? > Sorry I did not actually answer this question. This should be safe to keep. It is only problematic for cases where multiple singleton bundles are installed. This is typically something that p2 tries to avoid. I am not entirely sure why p2 is deciding that both versions of this extension need to be installed. We may need a separate p2 bug open to report this and get input from the p2 team as to why this may be happening.
Hi Thomas, there's only one thing that is not clear to me. Is the fact that we have two versions of org.codehaus.groovy.frameworkadapter a problem or not? So, are we talking about one or two bugs entirely related to Eclipse/p2 or is there a Groovy Eclipse plugin responsibility too?
(In reply to comment #15) > Hi Thomas, > there's only one thing that is not clear to me. Is the fact that we have two > versions of org.codehaus.groovy.frameworkadapter a problem or not? It is problematic since I do not think it is expected to have both versions installed at the same time. At least I can think of no good reason that both fragments should be installed. > > So, are we talking about one or two bugs entirely related to Eclipse/p2 or is > there a Groovy Eclipse plugin responsibility too? There is this bug which I suggest should stay against the Equinox->Framework to better handle when multiple versions of a framework extension are installed. I think there is a second issue here related to the reason we have multiple versions of org.codehaus.groovy.frameworkadapter installed at all. This could be either a p2 issue or an issue with the p2 metadata for the org.codehaus.groovy p2 repository. I suggest someone opens a separate bug report against Equinox->p2, hopefully with some steps to reproduce and the p2 team can have a look to determine if it is a p2 issue or an issue with the metadata of the repository.
(In reply to comment #16) > org.codehaus.groovy p2 repository. I suggest someone opens a separate bug > report against Equinox->p2, hopefully with some steps to reproduce and the p2 > team can have a look to determine if it is a p2 issue or an issue with the > metadata of the repository. I think it's quite hard to get some steps to repro. I may try to write first to Groovy Eclipse forums/mailing lists to determine if it's normal that both versions are installed.
Looking at my bundles.info, I see that I have: org.codehaus.groovy.frameworkadapter,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110921-1600-e37.jar,4,false org.codehaus.groovy.frameworkadapter,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.frameworkadapter_2.6.1.xx-20120107-0800-e37.jar,4,false Actually, I have duplicate entries for each of the plugins contributed by Groovy. What I can say is that: - 2.5.2 version was installed from http://dist.springsource.org/release/GRECLIPSE/e3.7/ - 2.6.1 version was installed from http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/ Can this information be useful for you?
(In reply to comment #18) > Looking at my bundles.info, I see that I have: > > org.codehaus.groovy.frameworkadapter,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110921-1600-e37.jar,4,false > org.codehaus.groovy.frameworkadapter,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.frameworkadapter_2.6.1.xx-20120107-0800-e37.jar,4,false > > Actually, I have duplicate entries for each of the plugins contributed by > Groovy. > What I can say is that: > - 2.5.2 version was installed from > http://dist.springsource.org/release/GRECLIPSE/e3.7/ > - 2.6.1 version was installed from > http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/ > > Can this information be useful for you? Perhaps it would to the p2 team, could you open a bug against p2 about this and give the details there? Thanks.
(In reply to comment #19) > Perhaps it would to the p2 team, could you open a bug against p2 about this and > give the details there? Thanks. I opened bug 368251.
Thanks for looking into this, Thomas. You're right that the fragment should have been marked as a singleton. I'll be doing that now and creating a new snapshot build of Groovy-Eclipse. Hopefully, this will address https://jira.codehaus.org/browse/GRECLIPSE-1325.
Fixed in commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=bef1cc9df1203fe05e5781dbe7b015f317a70cf5
