Description of problem: When running eclipse and trying to startup another eclipse without providing a -data command line argument, Eclipse complains that the workspace is in use, but does not prompt the user to select another location for the workspace. When running the second instance with -vm <ibm-jre> this does not happen, i.e. Eclipse correctly promps for an alternative workspace location when the default one is already open. Version-Release number of selected component (if applicable): 3.1.1-1jpp_1fc.FC4.4 and later How reproducible: Always Steps to Reproduce: 1. Run eclipse. 2. Run eclipse again (native). 3. Observe no prompt after error message. Actual results: Eclipse does not prompt for an alternative workspace location. Expected results: Eclipse should prompt for an alternative workspace location when the default one is in use.
I've been looking into this, and it appears that we somehow default to ~/workspace but running under the Sun JVM does not. Updating summary to reflect this.
Adding Tom Tromey and Andrew Haley After some investigation, it appears that it's some sort of native-compilation issue. When I remove /usr/lib/gcj/eclipse/org.eclipse.ui.ide_3.1.1.jar.db and rebuild-gcj-db, starting up Eclipse prompts me for a workspace location. One could argue that using ~/workspace as the default when no -data argument is provided is the correct behaviour, but it's odd that the .so is somehow affecting this. How can I debug this further? Also, this is entirely independent of /etc/eclipse.conf (which I think we should stop shipping now that we're not using the wrapper script).
> How can I debug this further? To begin with, please find the code in Eclipse that prompts for an alternative workspace. Let us know where it is, and we can look at the logic and decide how to debug it.
(In reply to comment #3) > [...] please find the code in Eclipse that prompts for an alternative > workspace. Let us know where it is, and we can look at the logic and decide how > to debug it. The relevant code is in org.eclipse.ui.internal.ide.IDEApplication around line 220. This code is in the org.eclipse.ui.ide CVS module at: cvs -d :pserver:anonymous.org:/cvsroot/eclipse co -r R3_1_2 \ org.eclipse.ui.ide vim +220 src/org/eclipse/ui/internal/ide/IDEApplication.java Checking out in Eclipse is best, because then you can right-click on the plugin.xml, hit PDE Tools->Create Ant Build File and then right-click on the resulting build.xml and Run As->Ant build... and check build.update.jar. The resulting jar can then be natively-compiled. I usually move the jar in /usr/share/eclipse/plugins to .bak and symlink to my workspace jar. I also remove the corresponding .db file (/usr/lib/gcj/eclipse/org.eclipse.ui.ide_3.1.1.jar.db in this case) and `sudo rebuild-gcj-db`. Let me know what I can do to help.
Okay, lots more information here. 1. I tried debugging with gdb but there seems to be some sort of screwup with the debug information. If I look at the output of `readelf -wil`, I can see that IDEApplication.java is file #79 in the file table 79 3 0 0 IDEApplication.java 80 3 0 0 IDEWorkbenchAdvisor.java but if we look at the DWARF information for file 79, all of the line # information is missing: <2><67886>: Abbrev Number: 12 (DW_TAG_subprogram) DW_AT_sibling : <67916> DW_AT_external : 1 DW_AT_name : checkInstanceLocation DW_AT_decl_file : 79 --> DW_AT_decl_line : 0 DW_AT_MIPS_linkage_name: _ZN3org7eclipse2ui8internal3ide14IDEApplication21checkInstanceLocationEPNS0_3swt7widgets5ShellE DW_AT_type : <5f6> DW_AT_accessibility: 3 (private) DW_AT_declaration : 1 *However*, file #80 in the file table has DWARF information that appears to be exactly what I'm looking for: <2><67f73>: Abbrev Number: 16 (DW_TAG_formal_parameter) DW_AT_name : (indirect string, offset: 0x7e27): this DW_AT_decl_file : 80 DW_AT_decl_line : 181 DW_AT_type : <67c6c> DW_AT_location : 2 byte block: 91 0 (DW_OP_fbreg: 0) <2><67f81>: Abbrev Number: 16 (DW_TAG_formal_parameter) DW_AT_name : (indirect string, offset: 0xa1a4): shell DW_AT_decl_file : 80 DW_AT_decl_line : 181 DW_AT_type : <1150> DW_AT_location : 2 byte block: 91 4 (DW_OP_fbreg: 4) Line 181 of IDEApplication.java is a method declaration with an argument of shell but this takes us to IDEWorkbenchAdvisor.java instead. This could be related to this: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00227.html 2. I added print statements and the output differs (obviously) when run with the .so and .db in place. I'll attach the two logs and the patches I created.
Created attachment 125038 [details] patch to org.eclipse.ui.ide R3_1_2 to generate debugging statements
Created attachment 125039 [details] patch to org.eclipse.core.runtime R3_1_2 to generate debugging statements
Created attachment 125040 [details] startup log when .so and .db are in place with previous patches
Created attachment 125041 [details] startup log when run interpreted with previous patches
I'm working on this.
This isn't a bug in gcj, it's a race condition in Eclipse. If you call org.eclipse.core.runtime.internal.adaptor.BasicLocation.getURL(), this has the side effect of setting the location field to its default value. The test in org.eclipse.ui.internal.ide.IDEApplication.checkInstanceLocation(org.eclipse.swt.widgets.Shell) assumes that no-one has ever called getURL() on this Location before, and it uses that as a test to see if it should prompt the user. However, org.eclipse.core.internal.runtime.DataArea.assertLocationInitialized() does this: Location service = InternalPlatform.getDefault().getInstanceLocation(); if (service == null) throw new IllegalStateException(Messages.meta_noDataModeSpecified); try { URL url = service.getURL(); which has the side-effect of setting the default location, so if this code is called before IDEApplication.checkInstanceLocation() the prompt will not be displayed. This is called by LocalMetaArea.hasSavedWorkspace() which is called from org.eclipse.core.resources.ResourcesPlugin.startup(). It's an accident that this ever worked.
Thanks for tracking this down, Andrew. I'll file it upstream.
I should file this in platform-runtime.
I suppose so. The logic is rather convoluted, so it's possible I may be mistaken, Even if I am, getURL()'s side-effect is surely bad coding practice, and depending on that side-effect is worse. I'd like someone else to look at the code to see if they agree with me.
I just noticed that eclipse prompts for the workspace if you run the binary directly (i.e. /usr/lib/eclipse/eclipse). Andrew O., why is the binary in the this directory? I moved it to /usr/bin as a test and it works fine. I'm going to move it to %{_bindir} and remove all the symlinks. This is needed for the multilib work, but it's nice that it fixes this problem too.
Actually, I jumped the gun with the last comment. I was using and upstream download with GCJ to get the prompt - not sure why that's working when our build doesn't work. Also, moving the eclipse binary to /usr/bin doesn't work so we'll have to make a patch for that so that multilib is handled correctly.
I disabled aot compiling the ui.ide plugin in the latest build as a temporary work-around for this problem.
The workaround in FC-6 updates and rawhide.
Can we close?