Community
Participate
Working Groups
Version: Luna (4.4) Build id: I20140606-1215 All tests (23 tests) in LeakTestSuite of org.eclipse.jdt.ui.tests are failed on JDK9 with error below: java.lang.SecurityException: Cannot make java.lang.Class.classLoader accessible at java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) at org.eclipse.jdt.ui.leaktest.reftracker.ReferenceTracker.setAccessible(ReferenceTracker.java:111) at org.eclipse.jdt.ui.leaktest.reftracker.ReferenceTracker.followFieldReference(ReferenceTracker.java:67) at org.eclipse.jdt.ui.leaktest.reftracker.ReferenceTracker.visit(ReferenceTracker.java:152) at org.eclipse.jdt.ui.leaktest.reftracker.ReferenceTracker.start(ReferenceTracker.java:176) at org.eclipse.jdt.ui.leaktest.LeakTestCase.collect(LeakTestCase.java:57) at org.eclipse.jdt.ui.leaktest.LeakTestCase.assertInstanceCount(LeakTestCase.java:120) at org.eclipse.jdt.ui.tests.leaks.JavaLeakTest.testJavaEditorCloseOneOfTwo(JavaLeakTest.java:161) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:657) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:310) at org.eclipse.test.UITestApplication$2.run(UITestApplication.java:197) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4147) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3764) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135) at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:140) at org.eclipse.test.UITestApplication.run(UITestApplication.java:62) at org.eclipse.test.UITestApplication.start(UITestApplication.java:212) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) at org.eclipse.core.launcher.Main.main(Main.java:34) Environment: 1. eclipse-Automated-Tests-4.4 from http://download.eclipse.org/eclipse/downloads/drops4/R-4.4-201406061215/ 2. jdk9 from http://jdk9.java.net/download
LeakTest started to fail with JDK9 b23.
This is not a framework issue. It would appear that java 9 has a check for setting the classLoader field even with no security manager.
*** Bug 527350 has been marked as a duplicate of this bug. ***
(In reply to Stephan Herrmann from comment #3) > *** Bug 527350 has been marked as a duplicate of this bug. *** As of Oxygen.1a and Java 9 GA I see a slightly different error java.lang.reflect.InaccessibleObjectException: Unable to make field private final jdk.internal.loader.BuiltinClassLoader jdk.internal.loader.BuiltinClassLoader.parent accessible: module java.base does not "opens jdk.internal.loader" to unnamed module @b97bc80 After playing with --add-opens java.base/jdk.internal.loader=ALL-UNNAMED I get the next error as java.lang.reflect.InaccessibleObjectException: Unable to make field private static final java.util.Map sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo.resourceNameToLocales accessible: module jdk.localedata does not "opens sun.util.resources.cldr.provider" to unnamed module @13674bcb at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:337) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:281) at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176) at java.base/java.lang.reflect.Field.setAccessible(Field.java:170) at org.eclipse.jdt.ui.leaktest.reftracker.ReferenceTracker.setAccessible(ReferenceTracker.java:111) All these cases seem to be unaffected by the default "--illegal-access=permit", because those classes appear in packages that did not exist in Java 8, see this from JEP 261 (my emphasis): "--illegal-access=permit opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, *if that package existed in JDK 8.*" Not sure if we have a chance to complete "open" all relevant modules, or whether skipping those types is better. Ff references escape our analysis this might defy the purpose of this test suite.
From experiments this list of options seems to do the trick: --add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens jdk.localedata/sun.util.resources.cldr.provider=ALL-UNNAMED --add-opens jdk.localedata/sun.util.resources.provider=ALL-UNNAMED --add-opens java.security.jgss/sun.security.krb5.internal.ssl=ALL-UNNAMED --add-opens java.base/java.lang.module=ALL-UNNAMED --add-opens java.base/jdk.internal.module=ALL-UNNAMED --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-opens java.base/jdk.internal.math=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED Now we only need to figure out how to pass these options for invocation by tycho.
Addendum: with comment 5 the first 11 tests succeed, but then we get s.t. spooky: java.lang.reflect.InaccessibleObjectException: Unable to make field private static java.lang.reflect.Method com.sun.proxy.jdk.proxy2.$Proxy29.m1 accessible: module jdk.proxy2 does not "opens com.sun.proxy.jdk.proxy2" to unnamed module @34ea5eff Why do I say spooky? That module jdk.proxy2 does not exist. --add-opens doesn't work for it. Dynamically generated? If so, how to add-opens in this case??
I ran LeakTestSuite locally with the options from comment #5. But I didn't get any error with the ghost module "jdk.proxy2". Tried with jdk-9+181 on Windows 7. Stephan, can you please check again?
(In reply to Noopur Gupta from comment #7) > I ran LeakTestSuite locally with the options from comment #5. But I didn't > get any error with the ghost module "jdk.proxy2". Tried with jdk-9+181 on > Windows 7. Stephan, can you please check again? Tried it again (with jdk-9.0.1), and now just adding the options from comment 5 is sufficient also on my box. I saw one assertion failure but perhaps that happened because i continued to work while tests were running - no configuration issue.
(In reply to Stephan Herrmann from comment #8) > Tried it again (with jdk-9.0.1), and now just adding the options from > comment 5 is sufficient also on my box. I saw one assertion failure but > perhaps that happened because i continued to work while tests were running - > no configuration issue. I also get one assertion failure even without touching the system while tests are running. This can be checked later once we fix the configuration issue: (In reply to Stephan Herrmann from comment #5) > Now we only need to figure out how to pass these options for invocation by > tycho.
Moving to M7.
I haven't checked in detail but listing down some hints here: In order to pass these vm args options for LeakTestSuite in build, I think we will have to make changes in or around org.eclipse.jdt.ui.tests\test.xml (see target with name "leaksuite" in it). PDE may have something similar in pde.api.tools.tests. To look for similar references in pde, do a file search for "-Dreq" in *.* on pde.api.tools.tests project.
FWIW, I was able to reproduce these test errors against Java 10 against a Tycho build. I figured I may as well test against that instead of 9. diff --git a/org.eclipse.jdt.ui.tests/pom.xml b/org.eclipse.jdt.ui.tests/pom.xml index c4c44dc384..34fcc96296 100644 --- a/org.eclipse.jdt.ui.tests/pom.xml +++ b/org.eclipse.jdt.ui.tests/pom.xml @@ -54,4 +54,26 @@ </plugins> </build> + <profiles> + <profile> + <activation> + <property> + <name>JAVA10</name> + </property> + </activation> + <build> + <plugins> + <plugin> + <groupId>org.eclipse.tycho</groupId> + <artifactId>tycho-surefire-plugin</artifactId> + <version>${tycho.version}</version> + <configuration> + <argLine>--add-modules ALL-SYSTEM --add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens jdk.localedata/sun.util.resources.cldr.provider=ALL-UNNAMED --add-opens jdk.localedata/sun.util.resources.provider=ALL-UNNAMED --add-opens java.base/jdk.internal.module=ALL-UNNAMED --add-opens java.base/java.lang.module=ALL-UNNAMED --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-opens java.base/jdk.internal.math=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED</argLine> + </configuration> + </plugin> + </plugins> + </build> + </profile> + </profiles> + </project> Which is pretty much what is mentioned in comment #5. The need for '--add-modules ALL-SYSTEM' seems to be specific to Tycho. The statement is probably in the equinox launch but might differ from how Tycho launches. Likely not needed in a PDE build though.
vmargs seems to work for the test.xml. I can run the tests as regular JUnit plugin tests and it works as expected, but am having some issues running with just the test.xml, although I can confirm the arguments get passed correctly. diff --git a/org.eclipse.jdt.ui.tests/test.xml b/org.eclipse.jdt.ui.tests/test.xml index 728db979e2..eb3568df41 100644 --- a/org.eclipse.jdt.ui.tests/test.xml +++ b/org.eclipse.jdt.ui.tests/test.xml @@ -49,6 +49,7 @@ <property name="data-dir" value="${jdt-folder}"/> <property name="plugin-name" value="${plugin-name}"/> <property name="classname" value="org.eclipse.jdt.ui.tests.LeakTestSuite"/> + <property name="vmargs" value="--add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens jdk.localedata/sun.util.resources.cldr.provider=ALL-UNNAMED --add-opens jdk.localedata/sun.util.resources.provider=ALL-UNNAMED --add-opens java.base/jdk.internal.module=ALL-UNNAMED --add-opens java.base/java.lang.module=ALL-UNNAMED --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-opens java.base/jdk.internal.math=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED"/> </ant> </target>
(In reply to Roland Grunberg from comment #13) > vmargs seems to work for the test.xml. I can run the tests as regular JUnit > plugin tests and it works as expected, I tried your changes in test.xml and it works fine. So, I think we can release it. > but am having some issues running > with just the test.xml, although I can confirm the arguments get passed > correctly. How are you trying this and where will it be required?
(In reply to Noopur Gupta from comment #14) > (In reply to Roland Grunberg from comment #13) > > vmargs seems to work for the test.xml. I can run the tests as regular JUnit > > plugin tests and it works as expected, > I tried your changes in test.xml and it works fine. So, I think we can > release it. Yes, I think it should. We would just need to use some conditional for activating only on java version >= 9 (${ant.java.version}) > > > but am having some issues running > > with just the test.xml, although I can confirm the arguments get passed > > correctly. > How are you trying this and where will it be required? I was using the eclipse-Automated-Tests-4.7.3a.zip, and eclipse-test-framework-4.7.3a.zip but wanted to run the test.xml (either out of Eclipse, or from cli). I ran into some issues getting fragments to resolve, or anything that had a requirement filter for osgi.os=linux osgi.arch=x86_64 . However, I could see the vmargs were passed correctly. I just wanted to test based on how the tests are actually run.
New Gerrit change created: https://git.eclipse.org/r/122980
Gerrit change https://git.eclipse.org/r/122980 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=2130ef06897813e3f6179c37245b0fe4e654a094
The tests are green in the latest I-build I20180521-2000. Thanks, Roland.
I notice that there's now 16 failures on macosx at the same time the 23 on the linux java 9 instance were resolved. It would seem to be related but I can't see what would have caused this. http://download.eclipse.org/eclipse/downloads/drops4/I20180521-0800/testresults/html/org.eclipse.jdt.ui.tests_ep48I-unit-mac64_macosx.cocoa.x86_64_8.0.html
(In reply to Roland Grunberg from comment #19) > I notice that there's now 16 failures on macosx at the same time the 23 on > the linux java 9 instance were resolved. It would seem to be related but I > can't see what would have caused this. > > http://download.eclipse.org/eclipse/downloads/drops4/I20180521-0800/testresults/html/org.eclipse.jdt.ui.tests_ep48I-unit-mac64_macosx.cocoa.x86_64_8.0.html > We just switched to a new Mac and there are focus issues. That's most likely causing the failures.
