Community
Participate
Working Groups
We have Eclipse installed in an AFS volume that is shadowed to multiple sites as a read-only volume. When you run eclipse the first time, it hangs showing the splash screen and gives the attached log. When you run eclipse a second time, it starts up just fine. If you delete ~/.eclipse, you can reproduce the problem. This problem occurs on both AIX and Linux. Note that we have added the following line to our config.ini osgi.locking = none and our configuration was initialized with eclipse -initialize. I'm not marking this bug as blocking since there is a workaround, but we would really like to have this fixed in 3.0.1 so we don't have to deal with hundreds of users asking why it's not working.
Created attachment 13449 [details] log file
Seems to be the same as in bug 70977 and bug 69782.
We've found a reasonable workaround for this problem. Delete ~/.eclipse directory Start eclipse and when you are prompted for your workspace, click cancel Tar ~/.eclipse direcotyr and place in the read-only fileset Create a wrapper script around eclipse such that when a user runs eclipse for the first time, it will un- tar the .eclipse directory from above into their home directory before running eclipse. Eclipse will then start without a NPE, and without hanging.
investigate the npes for 3.0.1. Bryan, note that to run eclipse in shared install mode, it is recommanded to run eclipse -initialize in the folder where eclipse is installed so the configuration, manifests, etc. are created and can then be shared by all users. Once this has been done mark the eclipse install as read only. Note that whenever you want to add a new plugin to the shared base by dropping it directly inside the folder, you'll have to re-initialize. If you want to add a plugin to the shared base using the update manager, set back the write access to the shared install, install the plugins, and set the rights to read only.
Created attachment 14231 [details] new startup.jar
Created attachment 14232 [details] new osgi.zip
Bryan, could you please try with this new startup.jar and a new osgi plugin to see if it fixes your problem.
I work with Bryan Hunt and I updated our install with the attached files and tried it again and I still get the null ptr exception (See end of note for contents of the .log file). Works fine the second time !SESSION Aug 27, 2004 17:01:31.139 --------------------------------------------- eclipse.buildId=I200406251208 java.fullversion=J2RE 1.4.1 IBM AIX build ca1411-20030930 (JIT enabled: jitc) BootLoader constants: OS=aix, ARCH=ppc, WS=motif, NL=en_US !ENTRY org.eclipse.ui 4 4 Aug 27, 2004 17:01:31.143 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 Aug 27, 2004 17:01:31.147 !MESSAGE java.lang.NullPointerException !STACK 0 java.lang.NullPointerException at org.eclipse.ui.internal.ide.IDEWorkbenchActivityHelper.loadNatures (IDEWorkbenchActivityHelper.java:110) at org.eclipse.ui.internal.ide.IDEWorkbenchActivityHelper.<init> (IDEWorkbenchActivityHelper.java:85) at org.eclipse.ui.internal.ide.IDEWorkbenchActivityHelper.getInstance (IDEWorkbenchActivityHelper.java:68) at org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.initialize (IDEWorkbenchAdvisor.java:173) at org.eclipse.ui.application.WorkbenchAdvisor.internalBasicInitialize (WorkbenchAdvisor.java:165) at org.eclipse.ui.internal.Workbench.init(Workbench.java:789) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1325) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:254) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:96) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:41) at java.lang.reflect.Method.invoke(Method.java:386) at org.eclipse.core.launcher.Main.basicRun(Main.java:183) at org.eclipse.core.launcher.Main.run(Main.java:664) at org.eclipse.core.launcher.Main.main(Main.java:648) !ENTRY org.eclipse.osgi Aug 27, 2004 17:01:31.306 !MESSAGE Error while stopping "org.eclipse.ui.ide_3.0.0". !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.compatibility.PluginActivator.stop() of bundle org.eclipse.ui.ide. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop (BundleContextImpl.java:1010) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:502) at org.eclipse.osgi.framework.internal.core.AbstractBundle.stop (AbstractBundle.java:437) at org.eclipse.core.runtime.adaptor.BundleStopper.basicStopBundles (BundleStopper.java:73) at org.eclipse.core.runtime.adaptor.BundleStopper.stopBundles (BundleStopper.java:62) at org.eclipse.core.runtime.adaptor.EclipseAdaptor.frameworkStopping (EclipseAdaptor.java:551) at org.eclipse.osgi.framework.internal.core.Framework.shutdown (Framework.java:457) at org.eclipse.osgi.framework.internal.core.SystemBundle$1.run (SystemBundle.java:182) at java.lang.Thread.run(Thread.java:568) Caused by: java.lang.NullPointerException at org.eclipse.core.runtime.Plugin.shutdown(Plugin.java:523) at org.eclipse.ui.plugin.AbstractUIPlugin.shutdown (AbstractUIPlugin.java:884) at org.eclipse.core.internal.compatibility.PluginActivator.stop (PluginActivator.java:74) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run (BundleContextImpl.java:994) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop (BundleContextImpl.java:990) ... 8 more Root exception: java.lang.NullPointerException at org.eclipse.core.runtime.Plugin.shutdown(Plugin.java:523) at org.eclipse.ui.plugin.AbstractUIPlugin.shutdown (AbstractUIPlugin.java:884) at org.eclipse.core.internal.compatibility.PluginActivator.stop (PluginActivator.java:74) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run (BundleContextImpl.java:994) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop (BundleContextImpl.java:990) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:502) at org.eclipse.osgi.framework.internal.core.AbstractBundle.stop (AbstractBundle.java:437) at org.eclipse.core.runtime.adaptor.BundleStopper.basicStopBundles (BundleStopper.java:73) at org.eclipse.core.runtime.adaptor.BundleStopper.stopBundles (BundleStopper.java:62) at org.eclipse.core.runtime.adaptor.EclipseAdaptor.frameworkStopping (EclipseAdaptor.java:551) at org.eclipse.osgi.framework.internal.core.Framework.shutdown (Framework.java:457) at org.eclipse.osgi.framework.internal.core.SystemBundle$1.run (SystemBundle.java:182) at java.lang.Thread.run(Thread.java:568) !ENTRY org.eclipse.osgi Aug 27, 2004 17:01:31.319 !MESSAGE Error while stopping "org.eclipse.core.resources_3.0.0". !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.compatibility.PluginActivator.stop() of bundle org.eclipse.core.resources. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop (BundleContextImpl.java:1010) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:502) at org.eclipse.osgi.framework.internal.core.AbstractBundle.stop (AbstractBundle.java:437) at org.eclipse.core.runtime.adaptor.BundleStopper.basicStopBundles (BundleStopper.java:73) at org.eclipse.core.runtime.adaptor.BundleStopper.stopBundles (BundleStopper.java:62) at org.eclipse.core.runtime.adaptor.EclipseAdaptor.frameworkStopping (EclipseAdaptor.java:551) at org.eclipse.osgi.framework.internal.core.Framework.shutdown (Framework.java:457) at org.eclipse.osgi.framework.internal.core.SystemBundle$1.run (SystemBundle.java:182) at java.lang.Thread.run(Thread.java:568) Caused by: java.lang.NullPointerException at org.eclipse.core.internal.compatibility.PluginActivator.stop (PluginActivator.java:76) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run (BundleContextImpl.java:994) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop (BundleContextImpl.java:990) ... 8 more Root exception: java.lang.NullPointerException at org.eclipse.core.internal.compatibility.PluginActivator.stop (PluginActivator.java:76) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run (BundleContextImpl.java:994) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop (BundleContextImpl.java:990) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker (BundleHost.java:502) at org.eclipse.osgi.framework.internal.core.AbstractBundle.stop (AbstractBundle.java:437) at org.eclipse.core.runtime.adaptor.BundleStopper.basicStopBundles (BundleStopper.java:73) at org.eclipse.core.runtime.adaptor.BundleStopper.stopBundles (BundleStopper.java:62) at org.eclipse.core.runtime.adaptor.EclipseAdaptor.frameworkStopping (EclipseAdaptor.java:551) at org.eclipse.osgi.framework.internal.core.Framework.shutdown (Framework.java:457) at org.eclipse.osgi.framework.internal.core.SystemBundle$1.run (SystemBundle.java:182) at java.lang.Thread.run(Thread.java:568)
Does this error occur while shutting down eclipse?
I get the window prompting me for the workspace and as soon as I hit ok, a message saying that I got a NullPtrException is written to the console. At that point eclipse seems to be hung so I killed the process and posted the contents of the log file. One thing I should point out is that we have a tool to shadow the code to several different IBM sites. So I make the changes in one site, the code is read/write for me at this site. Then the code is copied to the other sites into a read/only volume. I get the error running from here. Is it possible that something is in the configuration that is set that won't work with this shadowing scheme?
Brian, could you please provide me with more details on your configuration etc because I can not reproduce your problem. Moreover, when reproducing the problem, could you try with the options -consoleLog -console and give me the output of an "ss" in the console just before you click OK on the workspace dialog.
The fixes embodied in the given startup.zip and osgi.zip attachments have been committed to 3.0.1. Unfortunately, Brian reports in comment #8 that these did not help. This problem feels very much related but we are stumped. We need more information on how to reproduce or localize the problem. Can you start with the 3.0.1 RC1 build (tomorrow) and methodically reconstruct your scenario to see if it still happens. If it does, please provide any details you think relevant. If it doesn't, let us know.
*** Bug 70977 has been marked as a duplicate of this bug. ***
Could you please try with tomorrow 3.0.1 build, and run with the attached .options file and provide us with the log file. eclipse -debug d:/.options Thank you
Created attachment 14308 [details] a .option file to use for debug purpose
On the download site I do not see the 3.01 RC1 build. Should I use the lastest integration build?
Yes, RC1 == M20040901
Created attachment 14396 [details] log file from attempt with rc1 Log file that resulted from the fail when I ran eclipse from ro directory and no $HOME/.eclipse dir present
I ran with integration build M20040901 and here is what I found: 1. unzipped installed M20040901 in rw volume 2. ran eclipse -initialize on rw volume and shadowed to ro volume 3. removed my $HOME/.eclipse dir 4. ran eclipse from ro volume and IT CAME UP OK. 5. Using update manager I added our plugins to rw volume 6. ran eclipse -initialize on rw volume amd shadowed to ro volume 7. removed my $HOME/.eclipse dir 8. ran eclipse from ro volume and as soon as I selected the workspace I got the following error: Unhandled event loop exception Reason: Assertion failed: I have attached the .log file 9. I restarted eclipse and it came up ok
Brian, the log file attached is coming from an 3.1 and not 3.0.1. Can you attached a log with 3.0.1? Side note for me and others: I'm puzzled by the fact that installation through the update manager causes such a problem. Note that even so you change the content of the ro installation, users do not have to delete the .eclipse folder. By the way, could you provide me the config.ini file created in the .eclipse/configuration folder. Unmarking 3.0.1, because normal startup works and because I'm puzzled by the failure in the second part of the scenario. Brian, could you describe what is the "shadowing" operation. Does this somehow change drive letters or path to the files?
Some comments on deleting .eclipse and afs shawoding ... the other Brian will provide results after he downloads 3.0.1 We understand that users don't have to delete their .eclipse directory. However, we are deploying an application to a user base that has never used eclipse and therefore, they will not have a .eclipse directory the first time they run our application. Having to explain to our users why our application hangs the first time they start it is not good for business. We are installing eclipse in a RW afs fileset in a specific cell. This means that the RW path to eclipse and our plugins is something like: /afs/the_master_cell/some_sub_dirs/our_tool/eclipse/ this fileset is never directly accessed by users - instead, this fileset is shadowed (replicated, copied, duplicated, your_favorite_term_here) to other cells, physically in different cities, so that users local to that cell will have reasonable performance when running. The path the users will use will look something like: /afs/my_local_cell/some_sub_dirs/our_tool/eclipse/ Note, I'm moving the severity back to critical as our workaround described above does not work after further testing.
I did several experiments with the 3.01 integration build M20040908 and here are my observations: - if I just change the permission to make the dirs read only (no copy of data) I cannot reproduce the problem. - I can duplicate the error by doing the following: 1. install eclipse in dirs I have rw authority 2. add the following to the config.ini (osgi.locking = none needed because of problem with AFS) osgi.instance.area.default = @user.home/hdwb osgi.locking = none 3. run: eclipse -initialize 4. copy all files to new location 5. change permission so that I do not have write authority 6. rm $HOME/.eclipse (to simulate a new user) 7. from the ro dir run eclipse and I get the errors: Unhandled event loop exception Reason: java.lang.NullPointerException Note this was done with the base install. No other pluggins were loaded. Must have something to do with the copying of the files to a new directory. I will attach the log file
Created attachment 14447 [details] .log file with 3.01
I finally figured out what is happening. First of all, I want to notice you that initializing eclipse and then moving the install is useless since the caches retains fully qualified path. The only thing you gain with this practice is the sharing of the generated manifests. The bug can only be caused if the primary eclipse install (which is shadowed) is visible from the shadowed install. Therefore, in your case, if it is normal that the shadowed location can see the primary location, I suggest that once you shadowed the install, you move the primary install to another folder. If not then nothing special is required and everything will work properly. For records, here is what is happening and the setup. - Install eclipse in c:/eclipse1/eclipse - Initialize eclipse - Copy to (the copy is important) to c:/eclipse2/eclipse at this moment in eclipse2, the info in the bundledata all refers to the plugins from c:/eclipse1/eclipse. Therefore when the framework will start (the fwk folder used will be c:/eclipse2/eclipse) and will recreate the world it will find all the plugins and therefore everybody will be installed (in c:/eclipse1/eclipse). Then the configurator kicks in and realize that the plugins that are installed are not the one from c:/eclipse2/eclipse/plugins and will uninstall them all (except fwk & runtime) including org.eclipse.core.runtime.compatibility which has unfortunately already been started. Because runtime has a reference to compatibility that is not released when the bundles are refreshed, then the next time someone tries to get compatibility it will get an error saying that compatibility has been uninstalled (this only happens in debug mode). Questions to be answered: - why is compatibility not auto-started? - why does runtime forces the initialization of its plugin (for compatibility purpose) - doing ss the fwk was not displaying the status of the compatibility plugin properly
Your suggested workaround work for me. I will continue to rename the ro version after the shadowing is done until this bug is fixed. Thanks Since the workaround is acceptable you could reduce the severity of this issue.
Investigating bug 71630, I may have found the answer for two of your questions: - why is compatibility not auto-started? Don't know. Does it matter? - why does runtime forces the initialization of its plugin (for compatibility purpose) Runtime's activator extends the regular Plugin class. Plugin.start calls Plugin.initializeDescriptor, which forces the compatibility support to be loaded. This is an issue only during update scenarios, since during a fresh startup no compatibility support will be found at that time. - doing ss the fwk was not displaying the status of the compatibility plugin properly I guess this is because depending on which moment you check the framework state (before/after the configurator has run), you will see a different picture. One thing I do not understand: why do we eagerly initialize plugin descriptors? Plugin.getDescriptor seems to do the right thing but lazily, which is preferrable.
I found that this behavior is as old as revision 1.36 of the Plugin class (change described in bug 48191). I guess one way to prevent this would be to make the CompatibilityHelper smarter to react properly when the compatibility bundle is updated.
Created attachment 14517 [details] log containing the error from CompatibilityHelper This log entry is only created if org.eclipse.core.runtime/compatibility/debug=true is specified as a debug option.
*** Bug 71630 has been marked as a duplicate of this bug. ***
Hats off to Pascal for digging through this one. We should leave this (or a comparable) bug open until we have ironed out all the copy/move semantics for the runtime. It would be very (very) good if people could lay down preinitialized installs. This would allow for shipping off a CD (with no writable area) as well as eliminating the need for a configurator in many situations.
Created attachment 15179 [details] Log using the java -classpath startup.jar
Created attachment 15180 [details] Log using the eclipse executable
Hi, I am experiencing the same problem on a linux system. Eclipse 3.x is installed in /usr/local/eclipse /usr/local/eclipse/eclipse -initialize was done as root Attempt to run as user 'tusker' fails. Attached are two logs, one using the eclipse executable, and one using the java -classpath startup.jar. Please read the comments in the attached files too
*** Bug 78659 has been marked as a duplicate of this bug. ***
Created attachment 15877 [details] Make CompatibilityHelper aware of changes to compatibility Inserts a quick check to make sure the cached version of the compatibility bundle has not been unresolved or uninstalled. Checking the state of a bundle object should be a fast operation. The other option is to create another BundleListener or hook into the EclipseBundleListener from the registry. I think this would be more overhead and I would prefer to keep the registry code isolated from the compatibility code. Pascal, Rafael, please review and release if you are ok with the patch. I'm not sure if this patch will fix all the problems outlined in this bug, but it does fix bug 78659 which was dup'ed to this bug :)
Patch looks good to me. Some comments on how the reference is reset/updated might help.
The patch provided does not fix the whole problem described here, since upon configuration re-installation, the plugin descriptor for the runtime does not get reset. This needs to be investigated. For now the attach patch will be released to enable other teams to progress.
The patch has been released with additional comments suggested by comment 36. Leaving this bug open because there are still some dynamic issues that Pascal points out in comment 37.
Complementary fixes have been released in HEAD. Nature of the fix: - The plugin object for runtime no longer holds on to the plugin descriptor object - Compatibility plugin auto start and auto stop - Compatibility activator updated to clean up caches and unregister listeners.
Someone should delete the 3.0 milestones from bugzilla...
*** Bug 101061 has been marked as a duplicate of this bug. ***
