Community
Participate
Working Groups
My Eclipse (2018-12) crashes on two different Linux machines with the following error cairo-surface.c:955: cairo_surface_destroy: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. The crash happens when a larger Papyrus diagram (with embedded SVG images) is opened or zoomed in/out. While the error could certainly be in Papyrus, the bug is not reproducible on a Windows machine, so likely specific to the SWT/GTK implementation. The bug is reproducible with the Papyrus for Robotics RCP (eclipse.org/papyrus/components/robotics) when opening a certain diagram, the associated model is available on request. The 1st machine is an Ubuntu 16.04 one with GTK version 3.18.9, the 2nd one an Ubuntu 18.04 with GTK version 3.22.30.
Could you provide an SWT snippet that reproduces the issue?
In reply to Eric Williams from comment #1) > Could you provide an SWT snippet that reproduces the issue? unfortunately no. In the moment, I've just observed that my Papyrus/Eclipse installation crashes very often (but not always) when I open a larger diagram of a model using Linux whereas I cannot reproduce this issue with Windows. The problem can be reproduced in a 2nd (debug) Eclipse instance as well as in normal use. I could add the SWT sources to my first instance and try to debug into the issue (would appreciate some hints where to set breakpoints or similar). Alternatively, you could try to reproduce the error, if you install Papyrus for Robotics and I sent you a download link where you can find the model that triggers the error.
(In reply to Ansgar Radermacher from comment #2) > Alternatively, you could try to reproduce the error, if you install Papyrus > for Robotics and I sent you a download link where you can find the model > that triggers the error. Please do! Additionally, can you try on older releases (i.e. 4.9, or 4.8) and see if the issue reproduces there? This can help us narrow down a regression.
(In reply to Eric Williams from comment #3) > (In reply to Ansgar Radermacher from comment #2) > > Alternatively, you could try to reproduce the error, if you install Papyrus > > for Robotics and I sent you a download link where you can find the model > > that triggers the error. > > Please do! Additionally, can you try on older releases (i.e. 4.9, or 4.8) > and see if the issue reproduces there? This can help us narrow down a > regression. I can reproduce the error with Eclipse 2018-09, photon, oxygen and neon, i.e. this is not a regression. For the last two Eclipse versions, I used standard Papyrus as Papyrus for Robotics does not run on these Eclipse versions. With standard port shapes, the crash is not reproducible. But it can be triggered by activating SVG decorations on ports (via CSS). Thus, the error seems to be specific to the SVG display.
I can reproduce the crash as well.
The bug is still reproducible with 2019-03.
(In reply to Ansgar Radermacher from comment #6) > The bug is still reproducible with 2019-03. I have a new (faster) PC since a couple of days. While the exceptions happened "often" before, they now happen "almost always" if a diagram containing SVG shapes is opened. This might indicate that it is a threading issue.
I haven't forgotten about this bug, I'll try to take a look for 4.13.
Good news from my side. I can't reproduce the error with M3 of Eclipse 2019-06. It's not related to GTK version of the OS, since I can still reproduce the issues with 2019-03. So it has apparently been fixed - although it is not clear for me what has been done specifically. Should I close with "works for me?"
(In reply to Ansgar Radermacher from comment #9) > Good news from my side. I can't reproduce the error with M3 of Eclipse > 2019-06. It's not related to GTK version of the OS, since I can still > reproduce the issues with 2019-03. So it has apparently been fixed - > although it is not clear for me what has been done specifically. > Should I close with "works for me?" I think it might be fixed by bug 545032 -- I had to revert it for 4.12 RC1, but it's back in 4.13 now. Can you try with 4.12 RC1? If the issue *does* reproduce with that then we have our answer.
Yes, it's broken again in RC1 - I can reproduce the crash. So it will be fixed in the 2019-06 release?
(In reply to Ansgar Radermacher from comment #11) > Yes, it's broken again in RC1 - I can reproduce the crash. So it will be > fixed in the 2019-06 release? Yes, it's already fixed in master. To summarize: 4.12 M3 and earlier: fixed 4.12 RC1 and 4.12 GA: broken I20190610-1800 and newer: fixed Thanks for your help and investigation! *** This bug has been marked as a duplicate of bug 545032 ***
According to: https://bugs.eclipse.org/bugs/show_bug.cgi?id=545032#c43 this issue is back. Reopening the ticket.
Moving into 4.14 since I won't be able to get to this for 4.13.
(In reply to Eric Williams from comment #14) > Moving into 4.14 since I won't be able to get to this for 4.13. Hi Eric, any chance that this will be fixed for 4.14? Best Ansgar
(In reply to Ansgar Radermacher from comment #15) > (In reply to Eric Williams from comment #14) > > Moving into 4.14 since I won't be able to get to this for 4.13. > > Hi Eric, > > any chance that this will be fixed for 4.14? > > Best > > Ansgar Hoping to. I am making some changes to drawing code and this might get fixed as a result. Let me check back in a week or so.
Ansgar, can you try with a recent I-build? I20191027-1800 or newer should be good. Some changes were made to the internal drawing mechanism and I'm wondering if they've taken care of this issue.
(In reply to Eric Williams from comment #17) > Ansgar, can you try with a recent I-build? I20191027-1800 or newer should be > good. Some changes were made to the internal drawing mechanism and I'm > wondering if they've taken care of this issue. Hi Eric, I've installed an Eclipse-SDK from here: https://download.eclipse.org/eclipse/downloads/drops4/I20191028-1800/ (Version: 2019-12 (4.14) Build id: I20191028-1800) and then installed Papyrus for Robotics from its update-site. Unfortunately, I can immediately reproduce the crash: cairo-surface.c:955: cairo_surface_destroy: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed.
(In reply to Ansgar Radermacher from comment #18) > (In reply to Eric Williams from comment #17) > > Ansgar, can you try with a recent I-build? I20191027-1800 or newer should be > > good. Some changes were made to the internal drawing mechanism and I'm > > wondering if they've taken care of this issue. > > Hi Eric, > > I've installed an Eclipse-SDK from here: > https://download.eclipse.org/eclipse/downloads/drops4/I20191028-1800/ > (Version: 2019-12 (4.14) > Build id: I20191028-1800) and then installed Papyrus for Robotics from its > update-site. > > Unfortunately, I can immediately reproduce the crash: cairo-surface.c:955: > cairo_surface_destroy: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE > (&surface->ref_count)' failed. Sorry to hear it, I'll investigate.
Hi Eric, I did some investigations: I've added a check to cairo_surface_destroy, whether the reference count is already 0 (= already destroyed? Btw, it required a very small additional library, as cairo_surface_get_reference_count is not part of the functions exported via JNI). Thus, I was able to get a stack trace when the problem happens: Thread [Thread-71] (Suspended (breakpoint at line 1106 in Cairo)) Cairo.cairo_surface_destroy(long) line: 1106 Image.destroy() line: 928 Image(Resource).dispose() line: 69 SVGImage(AbstractRenderedImage).getSWTImage() line: 131 RenderHelper$1.run() line: 104 Thread.run() line: 748 Does this help? SVGImage is part of GMF-runtime. It is also possible that the root cause is not in SWT, but the Windows implementation if destroy surface will simply do nothing, if the ref count is already 0.
(In reply to Ansgar Radermacher from comment #20) > Hi Eric, > > I did some investigations: I've added a check to cairo_surface_destroy, > whether the reference count is already 0 (= already destroyed? Btw, it > required a very small additional library, as > cairo_surface_get_reference_count is not part of the functions exported via > JNI). > Thus, I was able to get a stack trace when the problem happens: > > Thread [Thread-71] (Suspended (breakpoint at line 1106 in Cairo)) > Cairo.cairo_surface_destroy(long) line: 1106 > Image.destroy() line: 928 > Image(Resource).dispose() line: 69 > SVGImage(AbstractRenderedImage).getSWTImage() line: 131 > RenderHelper$1.run() line: 104 > Thread.run() line: 748 > > Does this help? SVGImage is part of GMF-runtime. It is also possible that > the root cause is not in SWT, but the Windows implementation if destroy > surface will simply do nothing, if the ref count is already 0. The reference count already being 0 means the underlying OS resources associated with the Image (a Cairo surface in this case), have already been freed. I am wondering if the problem is that the SWT Image has already been disposed elsewhere and GMF is trying to dispose it unnecessarily. Could this be? As a side note, we recently added native SVG support on Linux: bug 545804. So if you are using a 3rd party library to load SVG Images you may want to take a look at refactoring it on Linux as you can probably gain some performance by having SWT do it directly.
> [...] > The reference count already being 0 means the underlying OS resources > associated with the Image (a Cairo surface in this case), have already been > freed. I am wondering if the problem is that the SWT Image has already been > disposed elsewhere and GMF is trying to dispose it unnecessarily. Could this > be? > > As a side note, we recently added native SVG support on Linux: bug 545804. > So if you are using a 3rd party library to load SVG Images you may want to > take a look at refactoring it on Linux as you can probably gain some > performance by having SWT do it directly. Thanks for your comments. I now have an idea what is going on. The class RenderHelper from GMF creates new images via getSWTImage in a rendering thread. The code of this method shown below disposes an eventual existing image - this could only happen, if another thread calls getSWTImage on the same image at the same time - in this case "dispose" could be called twice. in oe.gmf.runtime.draw2d.ui.render.internal.AbstractRenderedImage: final public Image getSWTImage() { if (img != null) return img; Image image = renderImage(); [calls SVGImage.renderImage in our case] if (img != null && !img.isDisposed()) { img.dispose(); } img = image; return img; } The issue does not happen any more, if I tag the getSWTImage above as "synchronized" (in this case the 2nd (img != null) check and eventual removal can be removed, as img is always null). The exception is also not reproducible any more, if I make the dispose method in swt.graphics.Resource "synchronized", but I rather think the culprit is the getSWTImage method.
I've created the new GMF-runtime bug 552568.
(In reply to Ansgar Radermacher from comment #23) > I've created the new GMF-runtime bug 552568. Perfect, thanks Ansgar for both your patience and your investigation into this issue.
