Bug 917418 - org.eclipse.swt.SWTException: Device is disposed
Summary: org.eclipse.swt.SWTException: Device is disposed
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Krzysztof Daniel
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-03-04 00:35 UTC by Stefan Neufeind
Modified: 2014-01-13 00:27 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-03-14 02:43:24 UTC
Type: Bug

Attachments (Terms of Use)
The .metadata/.log file (345.21 KB, text/plain)
2013-03-04 21:47 UTC, Chris Plummer
no flags Details

Description Stefan Neufeind 2013-03-04 00:35:38 UTC
 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:

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
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)

Comment 1 Stefan Neufeind 2013-03-04 00:35:58 UTC
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".

Comment 2 Krzysztof Daniel 2013-03-04 07:57:26 UTC
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.

Comment 3 Stefan Neufeind 2013-03-04 08:25:36 UTC
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.

Comment 4 Krzysztof Daniel 2013-03-04 08:33:12 UTC
Please consider running Eclipse with -clean startup parameter. The log does not contain any useful information.

Comment 5 Chris Plummer 2013-03-04 21:47:57 UTC
Created attachment 705187 [details]
The .metadata/.log file

Comment 6 Chris Plummer 2013-03-04 21:49:23 UTC
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.

Comment 7 Chris Plummer 2013-03-04 22:03:12 UTC
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'.

Comment 8 Roland Grunberg 2013-03-04 22:04:23 UTC
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 ?

Comment 9 Stefan Neufeind 2013-03-04 22:55:32 UTC
Works fine after update from 4.2.2-2 to 4.2.2-3.

Comment 10 Stefan Neufeind 2013-03-05 00:23:10 UTC
Going to 4.2.2-4 (from koji) it broke again. But 4.2.2-3 works fine for me.

Comment 11 Krzysztof Daniel 2013-03-05 07:38:45 UTC
with the update to 4.2.2-4 - have you also updated xml-commons-apis?

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.

Comment 12 Fedora Update System 2013-03-05 07:42:33 UTC
xml-commons-apis-1.4.01-11.fc18,eclipse-4.2.2-4.fc18 has been submitted as an update for Fedora 18.

Comment 13 Mary Ellen Foster 2013-03-05 13:23:04 UTC
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.

Comment 14 Mary Ellen Foster 2013-03-05 13:36:07 UTC
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! :)

Comment 15 Fedora Update System 2013-03-05 23:31:54 UTC
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:
then log in and leave karma (feedback).

Comment 16 Stefan Neufeind 2013-03-06 05:03:36 UTC
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.

Comment 17 Krzysztof Daniel 2013-03-06 06:54:26 UTC
(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.

Comment 18 Alexander Kurtakov 2013-03-06 06:57:11 UTC
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.

Comment 19 Fedora Update System 2013-03-14 02:43:26 UTC
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.

Comment 20 maochao 2013-06-27 15:43:20 UTC
I´ve erased the xml file workbench.xmi and eclipse open normally. Thank you. Eclipse JUNO updated today.

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