Working: eclipse-equinox-osgi x86_64 1:4.2.2-0.1.git20121217.fc18 eclipse-platform x86_64 1:4.2.2-0.1.git20121217.fc18 eclipse-swt x86_64 1:4.2.2-0.1.git20121217.fc18 After recent upgrade no longer working: eclipse-equinox-osgi-4.2.2-2.fc18.x86_64 eclipse-swt-4.2.2-2.fc18.x86_64 eclipse-platform-4.2.2-2.fc18.x86_64 Downgrading using yum helped. Full error: !ENTRY org.eclipse.equinox.event 4 0 2013-03-04 01:25:41.266 !MESSAGE Exception while dispatching event org.osgi.service.event.Event [topic=org/eclipse/e4/ui/model/ui/UIElement/parent/SET] to handler org.eclipse.e4.ui.services.internal.eve nts.UIEventHandler@6ce139a0 !STACK 0 org.eclipse.swt.SWTException: Device is disposed at org.eclipse.swt.SWT.error(SWT.java:4361) at org.eclipse.swt.SWT.error(SWT.java:4276) at org.eclipse.swt.SWT.error(SWT.java:4247) at org.eclipse.swt.widgets.Display.error(Display.java:1158) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4290) at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:187) at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:80) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:58) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.emf.common.notify.impl.NotificationImpl.dispatch(NotificationImpl.java:1027) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(NotifyingListImpl.java:718) at org.eclipse.emf.common.util.AbstractEList$EIterator.remove(AbstractEList.java:734) at org.eclipse.ui.internal.e4.compatibility.CompatibilityView.disposeSite(CompatibilityView.java:282) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.internalDisposeSite(CompatibilityPart.java:401) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.invalidate(CompatibilityPart.java:229) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.destroy(CompatibilityPart.java:387) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:861) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:841) at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:370) at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:127) at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:76) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:107) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:70) at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:171) at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:160) at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:160) at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:160) at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:160) at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:100) at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:131) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:847) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1568) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1504) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1499) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:681) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:600) at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:399) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:638) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:593) at org.eclipse.equinox.launcher.Main.run(Main.java:1447) at org.eclipse.equinox.launcher.Main.main(Main.java:1423)
Could it be the error at https://bugs.eclipse.org/bugs/show_bug.cgi?id=257970 is somehow related? I'm just guessing because of "Device is dispoed".
Hey Stefan, Thanks for taking time to fill this bug report. However, to proceed, I'll need more data. The exception that you've pasted is likely the effect, not the cause. I need your entire .log file, that can be found in your workspace/.metadata folder. Also, a short description of what does it mean "does not work" would be helpful.
Logfile sent to you offlist (might imho possibly contain private data). The problem occured right after starting Eclipse. It asked me where the workspace to be opened is located and after clicking okay it showed that an Exception occured and that it was logged to workspace/.metadata/.log.
Please consider running Eclipse with -clean startup parameter. The log does not contain any useful information.
Created attachment 705187 [details] The .metadata/.log file
I'm getting the same errors - whenever I start up Eclipse now, it breaks. If I blow away the .metadata folder, then recreate my entire workspace, then close Eclipse and start the same workspace again, I get the same problem. I also deleted open files in the workbench from the .metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi file, then re-opened Eclipse - it worked, then I closed Eclipse and started again, and it didn't work anymore. Running 'eclipse -clean' doesn't help either ... I've attached my log file just in case it helps.
Actually, I just tried a workaround of just blowing away the .metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi file, and doing so allows me to open the Eclipse workspace. I have to re-open the 'Java' perspective that I normally use (it defaults to only showing the 'Resource' perspective which I had closed previously), but all the other global settings stay the same (installed JRE/compiler settings/formatters/etc). I have to delete the file everytime I open Eclipse, but it does 'work'.
I reported a similar problem here : https://admin.fedoraproject.org/updates/FEDORA-2013-3244/eclipse-4.2.2-2.fc18?_csrf_token=f9328e1f42561c9da89dbe97177bb5bc9ff8c7f5 . When I tried out https://admin.fedoraproject.org/updates/FEDORA-2013-3401/eclipse-4.2.2-3.fc18?_csrf_token=f9328e1f42561c9da89dbe97177bb5bc9ff8c7f5 it solved this issue for me. Can anyone else confirm that 4.2.2-3 solves these issues for them ?
Works fine after update from 4.2.2-2 to 4.2.2-3.
Going to 4.2.2-4 (from koji) it broke again. But 4.2.2-3 works fine for me.
Stefan, with the update to 4.2.2-4 - have you also updated xml-commons-apis? http://koji.fedoraproject.org/koji/buildinfo?buildID=399776 Updated javax.xml should redirect classloading to system.bundle in the entire Eclipse, so no error would appear. If you update the 4.2.2-4 without updating xml-commons-api you are in a situation where part of plugins uses system.bundle, and the other part uses javax.xml - and this will cause maaaany issues.
xml-commons-apis-1.4.01-11.fc18,eclipse-4.2.2-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xml-commons-apis-1.4.01-11.fc18,eclipse-4.2.2-4.fc18
I've also been seeing similar issues that are only solved by deleting .metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi every time before I start eclipse -- exactly the same issues as those described in Comment #7. This is with 4.2.2-2; I'll try the 4.2.2-4 update and the xml-commons-apis update and report on the state shortly.
Update: I installed the packages from the pending update referred to in comment #12 and ran "eclipse -clean" once, and now both of my workspaces come up without any issues. Hooray! :)
Package xml-commons-apis-1.4.01-11.fc18, eclipse-4.2.2-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xml-commons-apis-1.4.01-11.fc18 eclipse-4.2.2-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-3470/xml-commons-apis-1.4.01-11.fc18,eclipse-4.2.2-4.fc18 then log in and leave karma (feedback).
Meanwhile I received 4.2.2-4 through updates-testing. Problem re-occured. Starting eclipse once with "eclipse -clean" however solved the problem. Weird. So finally it works. But I wonder if other people upgrading might run into problems.
(In reply to comment #16) > Meanwhile I received 4.2.2-4 through updates-testing. Problem re-occured. > Starting eclipse once with "eclipse -clean" however solved the problem. > Weird. Eclipse/OSGi could cache the existing bundles. -clean forces Eclipse to clean the cache. > So finally it works. But I wonder if other people upgrading might run into > problems. I'm not saying this will not happen. But I'm afraid I can't do much. Only the next version of Eclipse (Kepler) will have a support for seamless updates of master installation. Also, update from 4.2.1 to 4.2.2 should work without problems as many plugins are changed. The problem tends to appear when there is no version change (like we had multiple 4.2.2 updates). Sorry for the pain. Fedora 19 will be much better in this area.
Even upstream eclipse has many problems with shared installation and we suffer from that too - read as running with clean was needed many times. Krzysztof Daniel worked with upstream and in the next release the occurences of such problems should be really rare. I'm not saying not existing as it needs verifying in the wild and our rawhide packages already contains snapshots build with these changes.
xml-commons-apis-1.4.01-11.fc18, eclipse-4.2.2-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I´ve erased the xml file workbench.xmi and eclipse open normally. Thank you. Eclipse JUNO updated today.