Community
Participate
Working Groups
M6. Maybe a repro for Bug 304367. Already raised as an SWT issue: Bug 340113. Using the EclipseCon OCL Tutorial ZIPs at: http://www.eclipse.org/modeling/mdt/ocl/docs/publications/EclipseCon2011Tutorial/ZippedZip.zip and the install setup on the slides (M6 + Acceleo + GMF Runtime + OCL Examples + QVTo + UML2 + Xtext). Load the MainWorkspaceProjects into Eclipse. Run->Eclipse OCL Tutorial. Load the RuntimeWorkspaceProjects. Edit badsimple.states, which has no initial error markers. Run Generate BadStates. Bang Graphics Disposed issue. Problem may be the project refresh occurring while editor markers are changing.
Hi Ed, please provide the urls for the update sites that should be used to install the necessary plugins. Regards, Sebastian
Hi Sebastain All the plugins are in the releases/staging repo, which as I write, I think is still waiting for promotion to releases/indigo. My (draft) tutorial slides are now online at http://www.slideshare.net/EdWillink/enrich-your-models-with-ocl. Slide 5: Install Eclipse 3.7M6 Slide 6: Install Acceleo + GMF Run time + OCL Examples and Editors + Operational QVT + UML2 + Xtext Ignore Slide 7: (load an OCL M6a) Slide 8: Load projects from http://www.eclipse.org/modeling/mdt/ocl/docs/publications/EclipseCon2011Tutorial/MainWorkspaceProjects.zip (need to save to disk) Slide 9: Start Runtime Eclipse: Run->Eclipse OCL Tutorial Slide 10: Load projects from http://www.eclipse.org/modeling/mdt/ocl/docs/publications/EclipseCon2011Tutorial/RuntimeWorkspaceProjects.zip (need to save to disk) Edit ...playspace/model/badsimple.states Type three spaces to correct indentation of penultimate } [Do not save] Run->Generate BadSimple wait a couple of seconds Look at Console in Main Eclipse Initially shows "0s" then the Graphic Disposed appears once the project refresh kicks in. Return to Runtime Eclipse. Not repainting editors. Open another file: Graphic Disposed Popup occurs.
Ed, I added some guards to the ErrorTickUpdater. Please if the problem persists.
Problem persists with tmf-xtext-Update-N201103301931.zip. Fractionally different line numbers: org.eclipse.swt.SWTException: Graphic is disposed at org.eclipse.swt.SWT.error(SWT.java:4277) at org.eclipse.swt.SWT.error(SWT.java:4192) at org.eclipse.swt.SWT.error(SWT.java:4163) at org.eclipse.swt.graphics.Image.getBounds(Image.java:1164) at org.eclipse.swt.custom.CTabFolderRenderer.drawSelected(CTabFolderRenderer.java:1368) at org.eclipse.swt.custom.CTabFolderRenderer.draw(CTabFolderRenderer.java:537) at org.eclipse.swt.custom.CTabFolder.onPaint(CTabFolder.java:1727) at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:262) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
Ed, could you please provide a more conventient example that allows to reproduce the issue, e.g. attach a small sample project to this ticket. Thanks.
(In reply to comment #5) > Ed, could you please provide a more conventient example that allows to > reproduce the issue, e.g. attach a small sample project to this ticket. Thanks. I'll have a go once M7 is available consistently.
Still M6.5 (Xtext v201104061304) The problem is reproducible using the FowlerDSL example. Build the FowlderDSL editor. Start nested Eclipse. Create temp.fowlderdsl Control space to create default content delete "p" in "stop" so that editor is dirty with an error marker. Run an Acceleo M2T transformation launch coinfiguration. ... Graphics disposed IMHO both Acceleo and Xtext builders are over-enthusiastic, so probably one of them provokes a refresh that detects that the Xtext tick image is in an unheathy state. The only shared 'files' are the global EMF resources which may well be adjusted by Acceleo triggering the Xtext refresh.
Does Xtext change the image of its editor parts using setTitleImage(Image) or getTitleImage()?
We use #setTitleImage. Why do you ask?
(In reply to comment #9) > We use #setTitleImage. Why do you ask? Because the trace seems to suggest that the image that was previously set there to the tab item has been dispsoed.
This is what we do to update the title image. It would be really strange if that is disposed. if (titleImage != null && !titleImage.isDisposed() && editor != null) { editor.updatedTitleImage(titleImage); // public access to setTitleImage }
(In reply to comment #11) > This is what we do to update the title image. It would be really strange if > that is disposed. > > > if (titleImage != null && !titleImage.isDisposed() > && editor != null) { > editor.updatedTitleImage(titleImage); // public access to setTitleImage > } Based on your snippet above, that appears to only ensure that the one you are setting _now_ is not disposed. It doesn't guarantee that the one that used to be there ("the image that was previously set") hasn't been disposed.
This is what happens in #setTitleImage: protected void setTitleImage(Image titleImage) { Assert.isTrue(titleImage == null || !titleImage.isDisposed()); //Do not send changes if they are the same if (this.titleImage == titleImage) { return; } this.titleImage = titleImage; firePropertyChange(IWorkbenchPart.PROP_TITLE); if (imageDescriptor != null) { JFaceResources.getResources().destroyImage(imageDescriptor); imageDescriptor = null; } } Can you please elaborate on why it is relevant that the old title image is disposed or not? Furthermore I cannot image how this could happen. If you can provide some more details on your assumption, that would be helpful.
(In reply to comment #13) > Can you please elaborate on why it is relevant that the old title image is > disposed or not? Because as Edward seems to have observed, SWT will choke if this happens. > Furthermore I cannot image how this could happen. If you can > provide some more details on your assumption, that would be helpful. Just dispose the image right after you set it and you now have a disposed image set on the tab item. Image image = new Image(folder.getDisplay(), new Rectangle(0, 0, 16, 16)); Image image2 = new Image(folder.getDisplay(), new Rectangle(0, 0, 16, 16)); try { setTitleImage(image); image.dispose(); setTitleImage(image2); } finally { image.dispose(); image2.dispose(); }
I presume that you're not waiting for a repro from me any longer.
seems like the azeleo plugin install some bundles... EventManager$EventThread.postEvent(Set, EventDispatcher, int, Object) line: 374 ListenerQueue.dispatchEventAsynchronous(int, Object) line: 126 Framework.publishBundleEventPrivileged(BundleEvent) line: 1534 Framework.publishBundleEvent(BundleEvent) line: 1458 Framework.installWorker(String, PrivilegedExceptionAction, BundleContext) line: 897 Framework.installBundle(String, InputStream, BundleContext) line: 832 BundleContextImpl.installBundle(String, InputStream) line: 137 BundleContextImpl.installBundle(String) line: 131 AcceleoWorkspaceUtil.installBundle(String) line: 896 AcceleoWorkspaceUtil.installBundle(IPluginModelBase) line: 865 AcceleoWorkspaceUtil.refreshContributions() line: 683 AcceleoWorkspaceUtil.getClass(String, boolean) line: 469 AcceleoLaunchOperation.run(IProgressMonitor) line: 101 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2310 Workspace.run(IWorkspaceRunnable, IProgressMonitor) line: 2292 AcceleoPluginLaunchingStrategy.launch(IProject, String, String, File, List<String>, IProgressMonitor) line: 225 AcceleoPluginLaunchingStrategy.launch(ILaunchConfiguration, String, ILaunch, IProgressMonitor) line: 128 AcceleoLaunchDelegate.launch(ILaunchConfiguration, String, ILaunch, IProgressMonitor) line: 51 which causes the osgi event bus to dispatch bundle stop events to PluginImagaeHelper#bundleChanged which in turn disposes all loaded images...
i suggest to remove the PluginImageHelper bundlelistener registration and directly call the PluginImageHelper#dispose method from some kind of 'predestroy' lifecycle callback of the corresponding guice module or use the generated AbstractUIPlugin#stop instead.
Would it help to listen only for the bundle that produced the injector?
this method (dispose) actually never gets called for the corresponding ui bundle id 1. set a breakpoint in PIH#dispose 2. filter bundlevents matching the corresponding ui plugin 3. start runtime eclipse workspace 4. start/stop the ui plugin with the plugin registry view 5. stop the runtime eclipse workspace (In reply to comment #18) > Would it help to listen only for the bundle that produced the injector?
pushed to master.
Closing all bugs that were set to RESOLVED before Neon.0
