Community
Participate
Working Groups
NOTE: This may be multiple bugs. Sometimes after I shut down eclipse the call stack below, exhibit a, appears in the log file. Looks like sometimes DebugPlugin gets shutdown before LaunchingPlugin. This yields NPE as DebugPlugin.getDefault returns null after it is shutdown. When this happens I see the following launching plugin startup launching plugin shutdown launching plugin startup launching plugin shutdown <-- NPE The second startup ( instantiation ) of launching plugin is caused by the shutdown of IndexManager. ( See callstack exhibit b below ) I set breakpoints in DebugPlugin and Plugin to see if there was a problem there and nothing seemed to be wrong. At least there weren't any extra calls to DebugPlugin.startup that should have caused getDefault to return non-null afterwards. What I saw was in fact just debug plugin startup debug plugin shutdown ( setDefault( null ) ) NPE in launching plugin ------------------------------------- exhibit a ------------------------------- !MESSAGE FrameworkEvent.ERROR !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.compatibility.PluginActivator.stop() at org.eclipse.osgi.framework.internal.core.BundleContext.stop (BundleContext.java:1170) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:481) at org.eclipse.osgi.framework.internal.core.Bundle.suspend (Bundle.java:556) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle (Framework.java:1252) at org.eclipse.osgi.framework.internal.core.StartLevelImpl.decFWSL (StartLevelImpl.java:626) at org.eclipse.osgi.framework.internal.core.StartLevelImpl.doSetStartLevel (StartLevelImpl.java:277) at org.eclipse.osgi.framework.internal.core.StartLevelImpl.shutdown (StartLevelImpl.java:250) at org.eclipse.osgi.framework.internal.core.SystemBundle.suspend (SystemBundle.java:208) at org.eclipse.osgi.framework.internal.core.Framework.shutdown (Framework.java:603) at org.eclipse.osgi.framework.internal.core.SystemBundle$1.run (SystemBundle.java:193) at java.lang.Thread.run(Thread.java:534) Nested exception: java.lang.NullPointerException at org.eclipse.jdt.core.JavaCore.shutdown(JavaCore.java:3478) at org.eclipse.core.internal.compatibility.PluginActivator.stop (PluginActivator.java:67) at org.eclipse.osgi.framework.internal.core.BundleContext$2.run (BundleContext.java:1154) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContext.stop (BundleContext.java:1129) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:481) at org.eclipse.osgi.framework.internal.core.Bundle.suspend (Bundle.java:556) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle (Framework.java:1252) at org.eclipse.osgi.framework.internal.core.StartLevelImpl.decFWSL (StartLevelImpl.java:626) at org.eclipse.osgi.framework.internal.core.StartLevelImpl.doSetStartLevel (StartLevelImpl.java:277) at org.eclipse.osgi.framework.internal.core.StartLevelImpl.shutdown (StartLevelImpl.java:250) at org.eclipse.osgi.framework.internal.core.SystemBundle.suspend (SystemBundle.java:208) at org.eclipse.osgi.framework.internal.core.Framework.shutdown (Framework.java:603) at org.eclipse.osgi.framework.internal.core.SystemBundle$1.run (SystemBundle.java:193) at java.lang.Thread.run(Thread.java:534) --------------------------- exhibit b -------------------------------------- 2nd instance is created from java.lang.Exception at org.eclipse.jdt.internal.launching.LaunchingPlugin.<init> (LaunchingPlugin.java:269) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.eclipse.core.internal.plugins.PluginDescriptor.internalDoPluginActivation (PluginDescriptor.java:488) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation (PluginDescriptor.java:438) at org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin (PluginDescriptor.java:406) at org.eclipse.core.internal.compatibility.PluginActivator.start (PluginActivator.java:48) at org.eclipse.osgi.framework.internal.core.BundleContext$1.run (BundleContext.java:1054) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContext.startActivator (BundleContext.java:1050) at org.eclipse.osgi.framework.internal.core.BundleContext.start (BundleContext.java:991) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker (BundleHost.java:403) at org.eclipse.osgi.framework.internal.core.Bundle.start (Bundle.java:312) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtensio n(ConfigurationElement.java:133) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtensio n(ConfigurationElement.java:125) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtensio n(ConfigurationElement.java:114) at org.eclipse.jdt.core.JavaCore.getClasspathVariableInitializer (JavaCore.java:1342) at org.eclipse.jdt.core.JavaCore.getClasspathVariable (JavaCore.java:1280) at org.eclipse.jdt.core.JavaCore.getResolvedVariablePath (JavaCore.java:2262) at org.eclipse.jdt.core.JavaCore.getResolvedClasspathEntry (JavaCore.java:2180) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath (JavaProject.java:1856) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath (JavaProject.java:1790) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath (JavaProject.java:1762) at org.eclipse.jdt.internal.core.search.JavaSearchScope.add (JavaSearchScope.java:75) at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.initialize (JavaWorkspaceScope.java:78) at org.eclipse.jdt.internal.core.search.JavaSearchScope.<init> (JavaSearchScope.java:49) at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.<init> (JavaWorkspaceScope.java:30) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.shutdown (IndexManager.java:544) at org.eclipse.jdt.internal.core.JavaModelManager.shutdown (JavaModelManager.java:1441) at org.eclipse.jdt.core.JavaCore.shutdown(JavaCore.java:3481) at org.eclipse.core.internal.compatibility.PluginActivator.stop (PluginActivator.java:67) at org.eclipse.osgi.framework.internal.core.BundleContext$2.run (BundleContext.java:1154) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContext.stop (BundleContext.java:1129) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:481) at org.eclipse.osgi.framework.internal.core.Bundle.stop(Bundle.java:457) at org.eclipse.core.internal.plugins.PluginStopper.run (PluginStopper.java:101) at org.eclipse.core.internal.runtime.PlatformActivator.stopLegacyBundles (PlatformActivator.java:286) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:268) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:279) at org.eclipse.core.launcher.Main.run(Main.java:742) at org.eclipse.core.launcher.Main.main(Main.java:581)
Looks like JCORE is causing plug-in reactivation at shutdown. Moving for comment.
Good find, we were aware of this issue, but haven't seen it in a long time. We try to eliminate dead indexes during shutdown, and this may force some initializations of classpath variables/containers. The problem is that it is quite difficult to be sure an index file is unused whithout resolving the classpaths. Suggestions: 1- during shutdown: if we know we have all project classpaths resolved around, then we may do the index cleanup. If not, will let them in place, and rely on a subsequent opportunity to do so. 2- during workspace save action (like where we save build states), we could force it to perform resolution + cleanup, but on shutdown we can only do minimal work. My preference is 2. Starting point is: JavaModelManager#saving(ISaveContext) Index cleanup should only occur in FULL_SAVE mode.
*** Bug 51041 has been marked as a duplicate of this bug. ***
*** Bug 35021 has been marked as a duplicate of this bug. ***
Renamed IndexManager.shutDown() into cleanUpIndexes() and call it from JavaModelManager.saving(ISaveContext) in FULL_SAVE mode.
*** Bug 57797 has been marked as a duplicate of this bug. ***
Verified for 3.0 M9 with build I200405180816.
