Bug 175547 - Eclipse does not prompt for workspace when run natively
Eclipse does not prompt for workspace when run natively
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ben Konrath
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-12 11:53 EST by Igor Foox
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-14 07:21:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to org.eclipse.ui.ide R3_1_2 to generate debugging statements (3.84 KB, patch)
2006-02-22 11:52 EST, Andrew Overholt
no flags Details | Diff
patch to org.eclipse.core.runtime R3_1_2 to generate debugging statements (1.86 KB, patch)
2006-02-22 11:53 EST, Andrew Overholt
no flags Details | Diff
startup log when .so and .db are in place with previous patches (3.18 KB, patch)
2006-02-22 11:55 EST, Andrew Overholt
no flags Details | Diff
startup log when run interpreted with previous patches (3.18 KB, patch)
2006-02-22 11:55 EST, Andrew Overholt
no flags Details | Diff

  None (edit)
Description Igor Foox 2005-12-12 11:53:16 EST
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.
Comment 1 Andrew Overholt 2006-02-09 12:37:32 EST
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.
Comment 2 Andrew Overholt 2006-02-09 14:34:43 EST
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).
Comment 3 Andrew Haley 2006-02-10 05:44:44 EST
> 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.
Comment 4 Andrew Overholt 2006-02-10 11:37:22 EST
(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@dev.eclipse.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.
Comment 5 Andrew Overholt 2006-02-22 11:40:59 EST
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.
Comment 6 Andrew Overholt 2006-02-22 11:52:39 EST
Created attachment 125038 [details]
patch to org.eclipse.ui.ide R3_1_2 to generate debugging statements
Comment 7 Andrew Overholt 2006-02-22 11:53:18 EST
Created attachment 125039 [details]
patch to org.eclipse.core.runtime R3_1_2 to generate debugging statements
Comment 8 Andrew Overholt 2006-02-22 11:55:04 EST
Created attachment 125040 [details]
startup log when .so and .db are in place with previous patches
Comment 9 Andrew Overholt 2006-02-22 11:55:45 EST
Created attachment 125041 [details]
startup log when run interpreted with previous patches
Comment 10 Andrew Haley 2006-03-13 12:47:43 EST
I'm working on this.
Comment 11 Andrew Haley 2006-03-14 13:38:06 EST
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.
Comment 12 Andrew Overholt 2006-03-16 13:50:10 EST
Thanks for tracking this down, Andrew.  I'll file it upstream.
Comment 13 Andrew Overholt 2006-03-22 23:58:00 EST
I should file this in platform-runtime.
Comment 14 Andrew Haley 2006-03-23 05:00:35 EST
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.
Comment 15 Ben Konrath 2006-10-24 00:12:52 EDT
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.
Comment 16 Ben Konrath 2006-10-24 00:54:37 EDT
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.
Comment 18 Ben Konrath 2006-11-03 02:02:00 EST
I disabled aot compiling the ui.ide plugin in the latest build as a temporary
work-around for this problem.
Comment 19 Ben Konrath 2006-12-06 14:15:23 EST
The workaround in FC-6 updates and rawhide.
Comment 20 Andrew Overholt 2007-04-13 10:08:24 EDT
Can we close?

Note You need to log in before you can comment on or make changes to this bug.