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.
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).
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.
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.
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] ).
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.
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.
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.
*** Bug 1385212 has been marked as a duplicate of this bug. ***
(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.
(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.
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.
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.
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!).
(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.
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
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
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.