Community
Participate
Working Groups
Created attachment 256181 [details] Log file When I download the Eclipse Mars SDK (from [1]) and install New Software -> Mars -> GEF4 DOT SDK, the installation does not complain, but I can't open the DOT graph view, and the log contains dependency errors (see attached .log file). Works fine with the Java IDE Mars download. [1] http://download.eclipse.org/eclipse/downloads/drops4/R-4.5-201506032000/
That looks like an old "friend" (see bug #437107). Can you please try to install the LUNA compatibility features from our releases site and see whether that resolves the issue?
(In reply to Alexander Nyßen from comment #1) > That looks like an old "friend" (see bug #437107). Can you please try to > install the LUNA compatibility features from our releases site and see > whether that resolves the issue? I don't think it is Bug 437107, as the problem is not Guava but two bundles exposing javax.annotation: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.eclipse.gef4.fx [osgi.identity; osgi.identity="org.eclipse.gef4.fx"; type="osgi.bundle"; version:Version="0.1.0.201506081138"] because it is exposed to package 'javax.annotation' from resources org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.100.v20150529-1857"; singleton:="true"] and javax.annotation [osgi.identity; osgi.identity="javax.annotation"; type="osgi.bundle"; version:Version="1.2.0.v201401042248"] via two dependency chains. Chain 1: org.eclipse.gef4.fx [osgi.identity; osgi.identity="org.eclipse.gef4.fx"; type="osgi.bundle"; version:Version="0.1.0.201506081138"] require: (&(osgi.wiring.bundle=org.eclipse.osgi)(&(bundle-version>=3.9.0)(!(bundle-version>=4.0.0)))) | provide: osgi.wiring.bundle: [org.eclipse.osgi, system.bundle] org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.100.v20150529-1857"; singleton:="true"] Chain 2: org.eclipse.gef4.fx [osgi.identity; osgi.identity="org.eclipse.gef4.fx"; type="osgi.bundle"; version:Version="0.1.0.201506081138"] import: (&(osgi.wiring.package=com.google.common.reflect)(&(version>=12.0.0)(!(version>=16.0.0)))) | export: osgi.wiring.package=com.google.common.reflect; uses:=javax.annotation com.google.guava [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; version:Version="15.0.0.v201403281430"] import: (osgi.wiring.package=javax.annotation) | export: osgi.wiring.package: javax.annotation javax.annotation [osgi.identity; osgi.identity="javax.annotation"; type="osgi.bundle"; version:Version="1.2.0.v201401042248"] at org.eclipse.osgi.container.Module.start(Module.java:434) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) Guava just happens to import javax.annotation, but replacing this version of Guava with a different one wouldn't change a thing.
(In reply to Andreas Sewe from comment #2) > I don't think it is Bug 437107, as the problem is not Guava but two bundles > exposing javax.annotation: Yes, all your constraints seems to be consistently Guava 12 to 16, with 15 in use. But in anticipation of agreement on Bug 427862#c77 you might plan to allow use of Guava 18.
I was referring to my comment #21 there, where I faced pretty much the same problem.
(In reply to Alexander Nyßen from comment #1) After adding the LUNA compatibility features I get no errors during startup, I see the option to open the DOT graph view, but when I open it, I get a hard crash: fsteeg@aten:~/Downloads/eclipse$ ./eclipse -consolelog log4j:WARN No appenders could be found for logger (org.eclipse.xtext.ui.internal.Activator). log4j:WARN Please initialize the log4j system properly. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fbd2de29f6f, pid=7748, tid=140454660941568 # # JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libgdk-x11-2.0.so.0+0x4cf6f] gdk_display_open+0x3f # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/fsteeg/Downloads/eclipse/hs_err_pid7748.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Same if I do a fresh install of both the DOT SDK and the LUNA compatibility features from our release update site [1] into a Mars SDK. Attaching the details log for the second crash. [1] http://download.eclipse.org/tools/gef/gef4/updates/releases
Created attachment 256185 [details] Crash log
Opening dependencies to Guava 18 is on the list for Neon, for sure. But that is not the point here, as Mars is the target. The problem reported initially by Fabian (not the JRE crash, which I think is unrelated) also looks like the problem I had observed with the Luna SDK before (see bug #465682), which is why I had created respective Luna compatibility fragments (which seem to resolve the issue here as well). They contribute an unversioned package import for javax.annotation to circumvent the dependency chain issue in their respective GEF4 host bundles. I was not able to reproduce it with the Mars SDK so far (and thought the underlying issue to be resolved with Mars), but it seems the problem is not limited to Luna.
Fabian, could you please check whether the problem is also not reproducible with the Mars IDE for Eclipse Committers? This is the one I used in bug #465682 to confirm that the problem I had observed for Luna does no longer arise. I suppose some bundle has to be present in the IDE's that is missing in the SDK and (indirectly) resolves the dependency chain issue (probably via a dependency to java.annotation).
(In reply to Alexander Nyßen from comment #8) The dependecies seem to resolve, I see the option to open the DOT graph view, but when I do, I get the JRE crash both in the Mars IDE for committers and the Java IDE (with the DOT SDK from the Mars site and the GEF4 site, without the LUNA compatibility features, with fresh installs and workspaces).
(In reply to Fabian Steeg from comment #9) > (In reply to Alexander Nyßen from comment #8) > > The dependecies seem to resolve, I see the option to open the DOT graph > view, but when I do, I get the JRE crash both in the Mars IDE for committers > and the Java IDE (with the DOT SDK from the Mars site and the GEF4 site, > without the LUNA compatibility features, with fresh installs and workspaces). Just if I have understood that correctly, the dependency chain can be reproduced with the Mars SDK but with neither IDE, right? And it gets resolved (independent of the crash) with the compatibility fragments?
(In reply to Alexander Nyßen from comment #10) > Just if I have understood that correctly, the dependency chain can be > reproduced with the Mars SDK but with neither IDE, right? And it gets > resolved (independent of the crash) with the compatibility fragments? Yes, that is correct.
(In reply to Fabian Steeg from comment #11) > (In reply to Alexander Nyßen from comment #10) > > > Just if I have understood that correctly, the dependency chain can be > > reproduced with the Mars SDK but with neither IDE, right? And it gets > > resolved (independent of the crash) with the compatibility fragments? > > Yes, that is correct. Then I assume there has to be a bundle in the IDE's that is missing in the SDK, which probably provides a package import for javax.annotation. I think we should try to find that one.
I'm worried about the JRE crashes. I currently have no way to use the DOT view from our release on this machine at all (see comment 9). I've never dealt with JRE crashes like that before, any ideas what we could do about it?
As the problem seems to be related to native code, I fear the only thing we can do is to report it (http://bugreport.java.com/bugreport/crash.jsp) and see if Oracle can bring some light into the dark.
The crashes seem to be a GTK issue, found a workaround that works for me in [1]: Add to eclipse.ini: --launcher.GTK_version 2 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736#c50
(In reply to Fabian Steeg from comment #15) > The crashes seem to be a GTK issue, found a workaround that works for me in > [1]: > > Add to eclipse.ini: > > --launcher.GTK_version > 2 > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736#c50 Oh, yes, we also provide that information in our Contributor Guide. I was not aware you tried to run it with GTK 3 support. Thus its only the dependency resolution problem we need to tackle here.
(In reply to Alexander Nyßen from comment #16) > Oh, yes, we also provide that information in our Contributor Guide. I was > not aware you tried to run it with GTK 3 support. Me neither :-). I didn't enable or set anything about GTK. I'm also a bit confused about the wording in the contributor guide: "when running SWT on GTK 3 on older GTK versions". Is this a typo? Should the second "on" be "or"? But GTK 2, which works, is the older version?
(In reply to Fabian Steeg from comment #17) > (In reply to Alexander Nyßen from comment #16) > > > Oh, yes, we also provide that information in our Contributor Guide. I was > > not aware you tried to run it with GTK 3 support. > > Me neither :-). I didn't enable or set anything about GTK. Maybe, we should check for this error to give a hint to the user when starting on SWT with GTK 3 (within FX.UI, for example)? > I'm also a bit confused about the wording in the contributor guide: "when > running SWT on GTK 3 on older GTK versions". Is this a typo? Should the > second "on" be "or"? But GTK 2, which works, is the older version? Thank you, this is a typo.
*** Bug 478461 has been marked as a duplicate of this bug. ***
The remaining problem seems to be the same as the one reported in bug #478461. Thus resolving this as a duplicate. *** This bug has been marked as a duplicate of bug 478461 ***
