Community
Participate
Working Groups
Eclipse 4.17 Ecore Diagram Editor 3.3.2.201909230743 Mac OS Big Sur 11 Public Beta 5 (20A5384c) Big Sur will be released very soon. It seems that opening diagrams based on GEF/Draw2d/Sirius will completely crash Eclipse. 1. Create a new Ecore modelling project with all default settings 2. Make sure a viewpoint is selected in the New Project wizard (Archetype, Design or Review) 3. Press Finish in the wizard 4. Eclipse crashes Also can reproduce this by selecting an *.ecore file in the project and from the context menu, "Intialize Ecore Diagram..." or selecting the package and selecting "New Representation" and trying to generate a diagram. There is no stack trace in Eclipse. (FWIW we cannot open GEF/Draw2d diagrams in EditorParts in our RCP app either. It might be an SWT thing)
Hi. I don't have access to a mac. Can you provide any details about the crash? A stack trace or a JVM dump maybe? Which JRE are you using? Moving to Ecore Tools for now, but if it happens with other GEF/Draw2D diagrams the root of the issue is in lower parts of the stack.
Hi, the strange thing is that after rebooting a few time I can now create and diagrams. The same thing happened with our RCP application, "Archi". I could not open any diagrams and then I could. But one thing that crashes all the time is if you open the Outline View to show a thumbnail of the diagram. The cause of that is Draw2d's Thumbnail class and the root cause of that is in SWT - see Bug #543796 > Which JRE are you using? AdoptOpenJDK 11.0.8 although this makes no difference. These are SWT issues due to changes in MacOS Big Sur. Just be aware that users will see random crashes to do with drawing SWT images.
Further testing on MacOS Big Sur Beta 10. At least diagrams can be rendered. But as I said, the crasher is the Outline View to show a thumbnail of the diagram. The cause of that is Draw2d's Thumbnail class and the root cause of that is in SWT - see Bug #543796
Created attachment 284475 [details] Crash log when opening the Outline View Here's the crash log in case you're interested. The crash happens when the Outline View is open as well as a diagram. As I said, the issue is to do with SWT's GC class as used in org.eclipse.draw2d.parts.Thumbnail That Thumbnail class needs to be patched as mentioned in Bug 543796.
Moving to GEF if the root cause is there. Given that Draw2D is part of GEF Legacy which I believe is not maintained anymore, I'm not sure it will get fixed. It *might* be possible to work around it at the GMF Runtime level, which would benefit several projects, though not Archi I believe (it uses GEF directly, right?). Unfortunately I do not have much time to work on GMF at the moment, and do not have access to a mac. *If* someone wants to work on a patch at the GMF level and it feels safe enough I could include it in a future GMF maintenance release, but I can not do much more.
At the root, it is an SWT issue on Mac. The problem will be for end users using GMF/GEF/Draw2d based tools if they also open the Outline View on Mac Big Sur. For example, a user might create or open a diagram for an ECore Diagram Editor as part of an Eclipse Modelling Project and then "bam!" immediate crash to desktop and they won't know what caused it. Perhaps the bigger problem is GMF being built on GEF Legacy and Draw2d which is no longer maintained. But doesn't this also affect Sirius as this is based on that stack too?
(In reply to Pierre-Charles David from comment #5) > Moving to GEF if the root cause is there. > > Given that Draw2D is part of GEF Legacy which I believe is not maintained > anymore, I'm not sure it will get fixed. > > It *might* be possible to work around it at the GMF Runtime level, which > would benefit several projects, though not Archi I believe (it uses GEF > directly, right?). > > Unfortunately I do not have much time to work on GMF at the moment, and do > not have access to a mac. *If* someone wants to work on a patch at the GMF > level and it feels safe enough I could include it in a future GMF > maintenance release, but I can not do much more. What I don't understand is why Draw2D is not maintained and yet GMF and Sirius and tools like the Ecore diagram editor depend on it? Without Draw2D there would be no GMF or Sirius diagrams. How can these frameworks continue if this core component is not maintained?
(In reply to Phil Beauvoir from comment #7) > > What I don't understand is why Draw2D is not maintained and yet GMF and > Sirius and tools like the Ecore diagram editor depend on it? Without Draw2D > there would be no GMF or Sirius diagrams. How can these frameworks continue > if this core component is not maintained? I can't speak for the GEF project, but they are free to take their project in whatever direction they want, and they decided to move on to GEF 5 long ago. Feel free to ask GEF maintainers to take over the maintenance of GEF Legacy & Draw2D, as your own tool depends on them.
(In reply to Pierre-Charles David from comment #8) > (In reply to Phil Beauvoir from comment #7) > > > > What I don't understand is why Draw2D is not maintained and yet GMF and > > Sirius and tools like the Ecore diagram editor depend on it? Without Draw2D > > there would be no GMF or Sirius diagrams. How can these frameworks continue > > if this core component is not maintained? > > I can't speak for the GEF project, but they are free to take their project > in whatever direction they want, and they decided to move on to GEF 5 long > ago. > > Feel free to ask GEF maintainers to take over the maintenance of GEF Legacy > & Draw2D, as your own tool depends on them. I was simply curious how Sirius/GMF maintains its stack and fixes bugs that have a core dependency on Draw2d and legacy GEF.
Phil, just spotted this and wondering if you created an issue with just simple SWT snippet you attached to Bug #543796? (that still demonstrates that crash, presumably?) That way there's no denying there's problem with GC, surely?! ;) Pierre-Charles, as mentioned in that other bug (comment 23) this is the 2nd time GC has caused a hard crash. We had to fix the same problem happening in Nebula Grid when Mojave was released, see Bug #529920. In both cases the workaround is to not allocate the GC on the heap but to create a new one on the stack every time it's needed. Suspicious, no? And a performance hit.
(In reply to Justin Dolezy from comment #10) > Phil, just spotted this and wondering if you created an issue with just > simple SWT snippet you attached to Bug #543796? (that still demonstrates > that crash, presumably?) > > That way there's no denying there's problem with GC, surely?! ;) > > > Pierre-Charles, as mentioned in that other bug (comment 23) this is the 2nd > time GC has caused a hard crash. We had to fix the same problem happening in > Nebula Grid when Mojave was released, see Bug #529920. > > In both cases the workaround is to not allocate the GC on the heap but to > create a new one on the stack every time it's needed. Suspicious, no? And a > performance hit. Justin - do you mean did I create a new issue to demonstrate the GC crash with that snippet? No I didn't, do you think it needs a new issue? Another comment on this issue: What we have is an underlying issue with allocating a GC that can lead to incorrect drawing and a crash on MacOS Big Sur. This manifests in the Draw2D Thumbnail class which is used in the Content Outline View used by Ecore Diagram Editors and other GMF/Sirius diagrams. Also, saying that this is a legacy issue that won't be fixed is, IMHO, rather worrying - Draw2D is a core component of GMF/Sirius. It lies at the bottom of the stack and I believe is used to draw figures and do other drawing tasks. If something breaks in Draw2d or GEF then GMF/Sirius breaks too, surely? To say to the reporter of this bug (me) "Feel free to ask GEF maintainers to take over the maintenance of GEF Legacy & Draw2D, as your own tool depends on them" is not the right answer. I think that some people are in denial about how fundamental and crucial the "legacy" and "deprecated" Draw2D and GEF are to the GMF/Sirius frameworks.
(In reply to Justin Dolezy from comment #10) > Pierre-Charles, as mentioned in that other bug (comment 23) this is the 2nd > time GC has caused a hard crash. We had to fix the same problem happening in > Nebula Grid when Mojave was released, see Bug #529920. OK, but what can I do? From what I understand, the root cause is in SWT, and I'm not a commiter on SWT. It seems it could be worked around at the GEF level, but 1) GEF Legacy is not maintained, and 2) I'm not a committer there either. Maybe it could be worked around at the GMF Runtime level (where I am committer), which would help all GMF-based modelers (incl. Sirius, Papyrus, etc.), but not those like ArchiMate which use GEF directly. And again, I don't have access to a mac, so I can neither reproduce nor develop a fix or test potential patches provided by others (that I could only commit at the GMF or Sirius level anyway). The only real solution would be to get a fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=543796 right in SWT. Maybe the SWT team will have time to look at it now that EclipseCon is soon to be over.
Pierre-Charles - in this case the issue lies with SWT and, you are right, there is nothing you can do there. As for it manifesting in the Thumbnail View, there are workarounds as Justin and I have done. The immediate problem as far as Sirius/GMF/Ecore Diagram Editor is concerned is that opening the Content Outline View will totally crash to desktop for Mac users when Big Sur arrives very soon (and Big Sur will be pre-installed on new Macs). But perhaps the thing that needs to be addressed (by all stakeholders) is how to fix issues arising in Draw2D and GEF going forward when, as I said, GMF/Sirius/Other tools are built right on top of it. Perhaps workarounds can be made in GMF?
Draw2d/GEF (with almost no exceptions) has no platform specific code. Therefore, the reason for most of such kind of platform-specific problems lie within SWT. And as you already pointed out this seems to be the case here as well. Spending energy to get the underlying bug fixed in SWT is IMHO the better strategy compared to spending it on implementing a workaround on top. Concerning GEF Legacy, we have introduced our current, maintained code base more than five years ago, and the announcement of no longer maintaining the old legacy code base had been announced with an even greater initial leg. Indeed, "Feel free to ask GEF maintainers to take over the maintenance of GEF Legacy & Draw2D, as your own tool depends on them" is exactly the right answer. The GEF committers have no interest in spending our spare time on fixing bugs in a code base that is no longer relevant to ourselves. If the legacy code base is so fundamental and crucial, then funding the maintenance work should be no problem. Give me a proper budget and we will keep it alive as long as you want.
Alexander - this is not my point. Asking *me* to take over the maintenance of GEF Legacy & Draw2D is exactly the *wrong* answer. Nor am I asking you to maintain it. I really don't know how I can make my point any clearer, but I'll try again: Since higher-level frameworks such as GMF/Sirius/Papyrus all build on GEF3/Draw2D and use it as a *core* component for drawing I would have thought that perhaps some of those developers (and businesses built on using that stack) might have at least some interest in its well being. But perhaps not.
Phil I get your point. The only thing I can say to this is that, if there is a real interest in the well being of the legacy code base, it has not concretized itself in a proper funding of the required work. We have thus moved the Eclipse Legacy code base to GitHub, where it can easily be forked and maintained without relying on the GEF team, pretty much in the spirit of the LTS initiative that was once started (and AFAIK was closed down, not because it was such a great success). Concerning the concrete issue, I would propose to raise a bug with SWT (as already recommended in some of the comments), so the underlying problem can be properly addressed, and to then resolve this one as a duplicate (or invalid, as its not a GEF problem).
Thanks, Alexander. I've already kind of forked Draw2D and GEF for my own RCP application and patched where necessary. Clearly, this issue is an SWT issue and that has been reported. I was just taking the opportunity here also to raise awareness of the potential impact of the dependency on the legacy code, and if there is an issue further down the stack (Ecore Diagram -> Sirius -> GMF > Draw2D -> Thumbnail -> SWT) then it might bubble up and result in issues for the end user - like a crash.
Resolving as invalid, as not a GEF problem.
