Bug 1392150 - Eclipse doesn't start with a special workspace configuration
Summary: Eclipse doesn't start with a special workspace configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Roland Grunberg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1385212 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-05 10:17 UTC by Hedayat Vatankhah
Modified: 2017-01-19 05:55 UTC (History)
9 users (show)

Fixed In Version: eclipse-4.6.2-3.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-19 05:55:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi which causes Eclipse to not start (445.75 KB, application/xml)
2016-11-05 10:17 UTC, Hedayat Vatankhah
no flags Details

Description Hedayat Vatankhah 2016-11-05 10:17:34 UTC
Created attachment 1217543 [details]
workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi which causes Eclipse to not start

Description of problem:
With the attached workbench.xmi in workspace .metadata directory (.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi), eclipse won't start. It gets stuck in 'Loading org.eclipse.ltk.ui.refactoring'. Removing ltk/dltk related items from this file will make Eclipse to start fine.

Removing this line from the file lets Eclipse to run successfully:
<commands xmi:id="_1CdSUaNAEeamBIm6wuey7A" elementId="org.eclipse.dltk.ui.edit.text.script.refactor.quickMenu" commandName="Show Refactor Quick Menu" description="Shows the refactor quick menu" category="_1CVWh6NAEeamBIm6wuey7A"/>

Version-Release number of selected component (if applicable):
eclipse-gcov-5.1.0-1.fc25.noarch
eclipse-mylyn-versions-git-3.20.2-1.fc25.noarch
eclipse-mpc-1.5.2-1.fc25.noarch
eclipse-mylyn-tasks-bugzilla-3.20.2-1.fc25.noarch
eclipse-launchbar-2.0.1-1.fc25.noarch
eclipse-dltk-5.6.0-1.fc25.noarch
eclipse-emf-runtime-2.12.0-1.fc25.noarch
eclipse-remote-2.1.1-1.fc25.noarch
eclipse-e4-importer-0.2.0-0.2.gitb33919c.fc25.noarch
eclipse-swt-4.6.1-5.fc25.x86_64
eclipse-changelog-5.1.0-1.fc25.noarch
eclipse-linuxtools-libhover-5.1.0-1.fc25.noarch
eclipse-emf-core-2.12.0-1.fc25.x86_64
eclipse-manpage-5.1.0-1.fc25.noarch
eclipse-gef-3.11.0-1.fc25.noarch
eclipse-jgit-4.5.0-2.fc25.noarch
eclipse-cdt-qt-9.0.0-1.fc25.x86_64
eclipse-oprofile-5.1.0-1.fc25.noarch
eclipse-cmakeed-1.1.6-6.fc20.noarch
eclipse-egit-4.5.0-1.fc25.noarch
eclipse-gprof-5.1.0-1.fc25.noarch
eclipse-platform-4.6.1-5.fc25.x86_64
eclipse-mylyn-versions-3.20.2-1.fc25.noarch
eclipse-abrt-0.0.3-1.fc25.noarch
eclipse-mylyn-3.20.2-1.fc25.noarch
eclipse-p2-discovery-4.6.1-5.fc25.noarch
eclipse-ecf-core-3.13.2-1.fc25.x86_64
eclipse-tm-terminal-4.1.0-3.fc25.noarch
eclipse-egit-mylyn-4.5.0-1.fc25.noarch
eclipse-cdt-9.0.0-1.fc25.x86_64
eclipse-valgrind-5.1.0-1.fc25.noarch
eclipse-filesystem-1.0-7.fc24.x86_64
eclipse-epp-logging-2.0.3-1.fc25.noarch
eclipse-equinox-osgi-4.6.1-5.fc25.x86_64
eclipse-linuxtools-5.1.0-1.fc25.noarch
eclipse-jdt-4.6.1-5.fc25.noarch
eclipse-dtp-1.12.0-7.fc25.noarch
eclipse-mylyn-docs-wikitext-3.20.2-1.fc25.noarch
eclipse-mylyn-context-cdt-3.20.2-1.fc25.noarch
eclipse-systemtap-5.1.0-1.fc25.noarch
eclipse-pde-4.6.1-5.fc25.x86_64
eclipse-rpm-editor-5.1.0-1.fc25.noarch
eclipse-dltk-sh-5.6.0-1.fc25.noarch


How reproducible:
Right now, every time I open eclipse successfully once, the next time it doesn't start.

Comment 1 Roland Grunberg 2016-11-07 16:50:34 UTC
I wasn't able to reproduce this in a mock chroot with all rpms mentioned. My workbench.xmi did contain that entry (with just id and cateogry encoded differently).

Comment 2 Hedayat Vatankhah 2016-11-07 20:32:21 UTC
So the problem might be related to something else. If you have any suggestions to better debug the issue, please let me know. It is likely that creating a new workspace (or maybe with removing my ~/.eclipse) will solve the problem for me too. But it'd be better if the problem can be identified.

Comment 3 Hedayat Vatankhah 2016-11-09 10:28:25 UTC
Surprisingly, the bug seems to be no longer happening! I think it can be closed for now. 
(Sometimes ago I have a similar problem, but it stuck somewhere else (was related to sql or something similar). 
If happened again, I'll reopen it.

Comment 4 Roland Grunberg 2016-11-09 15:03:43 UTC
I ran into this yesterday and the only additional thing I can think of that caused it was it was a newly created workspace being started up for the n-th time ( n {- [2,5] ).

Comment 5 Roland Grunberg 2016-11-09 15:45:59 UTC
I've found a way to reproduce this. Not sure if it's the exact same issue everyone is seeing but certainly related to loading of the workbench.xmi. Just need a bit more time to narrow things down even more.

Comment 6 Sopot Cela 2016-11-09 16:45:45 UTC
The workbench.xmi is the persistence of the application model. This model holds the arrangement of views/perspectives/windows etc. So it might be related to a special arrangement of the perspective.

Comment 7 Roland Grunberg 2016-11-09 20:28:06 UTC
I'm able to reproduce this by starting on a fresh Eclipse workspace, and attempting to debug some java project and selecting "Yes" for the prompt that asks whether to open the Debug perspective for that session when a breakpoint is hit.

Looking in the error logs, I see stacktraces similar to :

!ENTRY org.eclipse.e4.ui.workbench 4 0 2016-11-09 14:00:56.893
!MESSAGE Unable to load resource file:/tmp/foo/workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi
!STACK 0
java.lang.NullPointerException
        at org.eclipse.e4.ui.internal.workbench.ResourceHandler.getResource(ResourceHandler.java:289)
        at org.eclipse.e4.ui.internal.workbench.ResourceHandler.loadResource(ResourceHandler.java:265)
        at org.eclipse.e4.ui.internal.workbench.ResourceHandler.loadMostRecentModel(ResourceHandler.java:169)
        at org.eclipse.e4.ui.internal.workbench.swt.E4Application.loadApplicationModel(E4Application.java:377)
        at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:252)
...
...

This happens at : http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.ui.workbench/src/org/eclipse/e4/ui/internal/workbench/ResourceHandler.java?h=R4_6_1#n289

The failures to load the workbench.xmi seem to be happening because the @PostConstruct init() in ResourceHandler ( http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.ui.workbench/src/org/eclipse/e4/ui/internal/workbench/ResourceHandler.java?h=R4_6_1#n99 ) is never triggered, so resourceSetImpl remains null in Fedora Eclipse. This is what ultimately leads to the NPE in getResource(URI uri). On an Upstream Eclipse it is triggered and this issue doesn't seem to occur.

If I look at the wiring for the 'javax.annoation' package I see :

g! packages javax.annotation

osgi.wiring.package; bundle-symbolic-name="javax.annotation-api"; bundle-version:Version="1.2.0"; version:Version="1.2.0"; osgi.wiring.package="javax.annotation"<javax.annotation-api_1.2.0 [7]>

  org.eclipse.e4.ui.workbench.addons.swt_1.2.100.v20160915-0852 [74] imports
  org.eclipse.e4.ui.workbench_1.4.0.v20160915-0852 [73] imports
  org.eclipse.e4.tools.emf.ui_4.5.100.v20160915-0852 [993] imports
  org.eclipse.e4.tools.services_4.5.0.v20160915-0852 [995] imports
  com.google.guava_18.0.0 [869] imports
  org.eclipse.e4.ui.workbench.renderers.swt_0.14.0.v20160915-0852 [75] imports
  org.eclipse.launchbar.ui.controls_1.0.0.201610040941 [1090] imports
  org.eclipse.e4.ui.workbench.swt_0.14.1.v20160915-0852 [76] imports
  org.eclipse.ui.workbench_3.108.1.v20160915-0852 [188] imports
  org.eclipse.e4.ui.css.swt.theme_0.10.100.v20160915-0852 [66] imports
  

osgi.wiring.package; bundle-symbolic-name:List<String>="org.eclipse.osgi,system.bundle"; bundle-version:Version="3.11.1.v20160915-0852"; version:Version="0.0.0"; osgi.wiring.package="javax.annotation"<org.eclipse.osgi_3.11.1.v20160915-0852 [0]>

  org.eclipse.e4.core.services_2.0.100.v20160915-0852 [61] imports
  org.eclipse.rse.services.dstore_3.3.0.201610041547 [1297] imports
  org.eclipse.cdt.debug.core_8.0.0.201609122005 [942] imports
  org.eclipse.emf.codegen.ui_2.6.0.v20160613-1000 [1012] imports
  ...
  ...
  everything else
  ...
  ...

It looks like the e4.ui.workbench plugins are being wired against the wrong javax.annotation. On the first startup they were fine but after performing the steps to reproduce, they seem to be wired differently.

Comment 8 Roland Grunberg 2016-11-09 20:41:38 UTC
*** Bug 1385212 has been marked as a duplicate of this bug. ***

Comment 9 Hedayat Vatankhah 2016-11-09 22:13:42 UTC
(In reply to Sopot Cela from comment #6)
> The workbench.xmi is the persistence of the application model. This model
> holds the arrangement of views/perspectives/windows etc. So it might be
> related to a special arrangement of the perspective.

What I can add is this: the day I reported the bug, when I removed my workbench.xmi completely, I could run Eclipse once. But the next try (after closing Eclipse without ANY customization, so the default setup. The only thing I might have done was to change the perspective from default to C++) it didn't run.

Comment 10 Roland Grunberg 2016-11-10 19:09:49 UTC
(In reply to Hedayat Vatankhah from comment #9)
> What I can add is this: the day I reported the bug, when I removed my
> workbench.xmi completely, I could run Eclipse once. But the next try (after
> closing Eclipse without ANY customization, so the default setup. The only
> thing I might have done was to change the perspective from default to C++)
> it didn't run.


Is there any possibility that you had another Eclipse instance (or Equinox runtime) that was running at the same time as your main Eclipse instance ?

The reason my method of reproduction worked was because the application I was debugging was an Equinox instance sharing the exact same configuration/install area as my main one. This likely caused some race conditions leading to the strange behaviour and re-wiring.

On the other hand your case doesn't mention any of these so there may well be some other way to produce the same errors you're seeing.

Comment 11 Hedayat Vatankhah 2016-11-10 22:02:22 UTC
No, I didn't have anything else running like that. And I don't know how the bug suddenly vanished after keeping Eclipse open for many hours.

Comment 12 Roland Grunberg 2016-11-16 19:05:52 UTC
It has been discussed that we remove javax.annotation-api because at least in Fedora we can say with certainty that everything should get javax.annotation* from the "system bundle".

I think this would solve the issue.

Comment 13 Hedayat Vatankhah 2016-12-18 14:44:08 UTC
Happened again today :(
Eclipse stop while "Loading org.eclipse.datatools.sqltools.sqleditor".
Removing workbench.xmi, eclipse started successfully. Closed & opened again: works fine.
Switched the perspective to C/C++ and closed. Problem appeared again.
System is F25 with latest updates (till a few hours ago!) applied. Haven't seen this problem in a while.

The problem might be actually related to an open SQL Editor window. However, I cannot confirm: after playing a little with perspectives & windows, now Eclipse crashes on start!

Removing workbench.xmi fixed the crash too. And now, Eclipse starts fine even in C/C++ perspective. I'm going to open an .sql file in SQL Editor and close Eclipse to see if it starts or not.

It didn't. It seems that there is really something wrong with my Eclips when an SQL file is open. This one is at least reproducible for now.
(Removing workbench.xmi and) Closing the SQL file in C/C++ perspective & opening a C++ file caused the crash again. 

Removing workbench.xmi again and switch to C/C++ workspace now works fine.

For now, I'll try to not keep any SQL Editors open when I close Eclipse. (I guess it didn't happen for a while for me because I didn't edit .sql file during this period!).

Comment 14 Mat Booth 2017-01-12 09:57:35 UTC
(In reply to Roland Grunberg from comment #12)
> It has been discussed that we remove javax.annotation-api because at least
> in Fedora we can say with certainty that everything should get
> javax.annotation* from the "system bundle".
> 
> I think this would solve the issue.

I tested to ensure that we don't this bundle and it works fine without. Although I have hard time reproducing the original problem, so I can't be sure it has fixed the workbench.xmi problem.

I will submit an update with Rolands' suggested fix -- but feel free to re-open if you continue to experience the problem after installing the update.

Comment 15 Fedora Update System 2017-01-12 23:27:07 UTC
ecj-4.6.2-1.fc25 eclipse-4.6.2-3.fc25 eclipse-dltk-5.7.0-1.fc25 eclipse-ecf-3.13.3-1.fc25 eclipse-egit-4.6.0-1.fc25 eclipse-egit-github-4.6.0-1.fc25 eclipse-epp-logging-2.0.3-2.fc25 eclipse-jgit-4.6.0-2.fc25 eclipse-mpc-1.5.3-1.fc25 eclipse-pdt-4.2.0-1.fc25 lucene4-4.10.4-7.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ddde4436aa

Comment 16 Fedora Update System 2017-01-13 08:31:15 UTC
ecj-4.6.2-1.fc25, eclipse-4.6.2-3.fc25, eclipse-dltk-5.7.0-1.fc25, eclipse-ecf-3.13.3-1.fc25, eclipse-egit-4.6.0-1.fc25, eclipse-egit-github-4.6.0-1.fc25, eclipse-epp-logging-2.0.3-2.fc25, eclipse-jgit-4.6.0-2.fc25, eclipse-mpc-1.5.3-1.fc25, eclipse-pdt-4.2.0-1.fc25, lucene4-4.10.4-7.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ddde4436aa

Comment 17 Fedora Update System 2017-01-19 05:55:24 UTC
ecj-4.6.2-1.fc25, eclipse-4.6.2-3.fc25, eclipse-dltk-5.7.0-1.fc25, eclipse-ecf-3.13.3-1.fc25, eclipse-egit-4.6.0-1.fc25, eclipse-egit-github-4.6.0-1.fc25, eclipse-epp-logging-2.0.3-2.fc25, eclipse-jgit-4.6.0-2.fc25, eclipse-mpc-1.5.3-1.fc25, eclipse-pdt-4.2.0-1.fc25, lucene4-4.10.4-7.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.


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