Impossible d'acquérir le verrou de changement d'état
Nos produits sont à l'aide de la dernière production de la libération de SWT, 3.7.2. Maintenant depuis pas à l'époque savait que la prochaine version de Java serait appelé (et comment pourraient-ils savoir que 8 est venu après le 7, c'est comme les mathématiques supérieures), nous avons été obligés de troquer le org.eclipse.osgi
de 3.7.2 pour 3.10.0, de sorte que nous pouvons maintenant de support de Java 8. Alors que c'est peut-être pas la meilleure des idées, en théorie, il devrait travail.
Bien sûr, étant le plus important vis-Eclipse Luna est, il y a cette "erreur" quand nous commençons à nos demandes (environ 50% du temps, je suppose):
org.osgi.framework.BundleException: Unable to acquire the state change lock for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; singleton:="true" [id=0] STARTED [STARTED] invalid
at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329)
at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:44)
at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:170)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)
at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
at org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:48)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936)
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319)
at org.eclipse.osgi.container.Module.doStart(Module.java:571)
at org.eclipse.osgi.container.Module.start(Module.java:439)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
at org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:242)
at org.eclipse.osgi.container.Module.doStart(Module.java:571)
at org.eclipse.osgi.container.Module.start(Module.java:439)
at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:172)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)
at org.eclipse.osgi.launch.Equinox.start(Equinox.java:115)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:320)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Il n'y a pas beaucoup d'informations sur le web ce que le problème est, la plupart des experts suggèrent juste à supprimer l'espace de travail, mais pour la plupart, il ne se produit lors du démarrage d'Eclipse, pas de la version finale des applications - néanmoins, j'ai supprimé les espaces de travail et l'exécution des dossiers. Rien n'y fait. Le "erreur" est lancée dans le produit exporté en tant que bien, mais autant que je peux dire, tout fonctionne toujours comme prévu.
Est-il un moyen de le réparer? Et si non, est-il un moyen de le cacher que stupide exception (désactiver la journalisation pour un moment, effacement de l'historique, que ce soit, je ne suis pas pointilleux)?
source d'informationauteur Steffi S.
Vous devez vous connecter pour publier un commentaire.
Cela ressemble le cadre de démarrage commence simpleconfigurator qui essaie de démarrer le cadre de nouveau. Le cadre détecte cette récursivité et déclenche une exception pour lui échapper. Le problème semble être dans simpleconfigurator de tenter de la démarrer le cadre de départ.
J'ai résolu le problème en suivant ces étapes simples,
J'ai fait face à un même problème.La suppression de la donnée .fichier journal à partir de dossier de configuration et redémarrer eclipse devrait résoudre votre problème.
- Je utiliser Red Hat Developer Studio 10.4 (Eclipse 4.6) et j'ai essayé d'utiliser Eclipse Checkstyle plugin.
Après l'installation j'ai redémarré mon IDE et a reçu le crash de notification.
J'ai essayé toutes les suggestions, mais seulement quand je supprime un fichier appelé
framework.info.34
mon problème a été résolu.Ce fichier est dans
%eclipse_home%/configuration/org.eclipse.osgi
dossier.Problème de pop-up après la mise à niveau de l'éclipse de néon, par le biais de la mise à jour du site avec l'installation de nouveaux plugins.
De l'étape 01:
Je l'ai enlevé .fileTable.* verrouillage des fichiers à partir de ${eclipse_home}/configuration/org.eclipse.osgi/.le gestionnaire de répertoire.
Étape 02:
Retiré osgi cache et autres plugins de cache en commençant dans eclipse propre mode
eclipse -propre
j'ai le même problème,
j'ai supprimé les fichiers de places respectives
1) "eclipse\configuration\org.eclipse.osgi.manager"
.fileTableLock
.fileTable3
.fileTable4
2) eclipse\configuration
*.journal
après que j'ai ouvert l'éclipse, il a travaillé avec tout le redémarrage de PC.
pour les gens qui ont ce problème jusqu'à ce que runing eclipse lors de l'exécution d'eclipse :
nettoyer dossier :
[yourEclipseSourceWorkspace]/.metadata/.plugins/org.eclipse.pde.core/[yourRunConfiguration]/org.eclipse.osgi/.le gestionnaire de
[yourEclipseSourceWorkspace]/.metadata/.plugins/org.eclipse.pde.core/[yourRunConfiguration]/org.eclipse.osgi supprimer tous les fichiers (pas de dossier)
puis ajouter à votre configuration -propre, programm arg