Details
-
Bug
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
-
Jenkins 2.155
Java 11
PCT
-
-
script-security 1.55
Description
When trying to validate script-security plugin with PCT for Java 11, I got test failures with the following output
java.lang.reflect.InaccessibleObjectException: Unable to make field private static final java.lang.module.Configuration java.lang.module.Configuration.EMPTY_CONFIGURATION accessible: module java.base does not "opens java.lang.module" to unnamed module @5ebd56e9
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)
at org.netbeans.insane.impl.InsaneEngine.processClass(InsaneEngine.java:238)
at org.netbeans.insane.impl.InsaneEngine.process(InsaneEngine.java:199)
at org.netbeans.insane.impl.InsaneEngine.traverse(InsaneEngine.java:97)
at org.netbeans.insane.impl.LiveEngine.traceImpl(LiveEngine.java:188)
at org.netbeans.insane.impl.LiveEngine.trace(LiveEngine.java:166)
at org.jvnet.hudson.test.MemoryAssert.fromRoots(MemoryAssert.java:292)
at org.jvnet.hudson.test.MemoryAssert.assertGC(MemoryAssert.java:178)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovyMemoryLeakTest.loaderReleased(GroovyMemoryLeakTest.java:62)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:548)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:834)
Acceptance criteria
- re-run PCT to see if still current
- if not, \o/. If still an issue, either fix it if very simple, or file a clearer JIRA with what needs fixing
Attachments
Issue Links
- links to
Activity
From at org.jvnet.hudson.test.MemoryAssert.fromRoots(MemoryAssert.java:292) at org.jvnet.hudson.test.MemoryAssert.assertGC(MemoryAssert.java:178) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovyMemoryLeakTest.loaderReleased(GroovyMemoryLeakTest.java:62) in that output, it looks to be something in jenkins-test-harness?
Adrien Lecharpentier
added a comment - you are totally right abayer and it seems I need a slap on the back of my head.. I just faced this only on script-security because I guess it's the only plugin I tested to use this function.
Adrien Lecharpentier
added a comment - you are totally right abayer and it seems I need a slap on the back of my head.. I just faced this only on script-security because I guess it's the only plugin I tested to use this function. Yeah, the problem is that MemoryAssert in jenkins-test-harness uses the Netbeans Insane Library to do live heap analysis, making it possible to do things like write a test to check for memory leaks (which is what script-security is doing). It looks like there are a few other uses of MemoryAssert, notably including workflow-job. There are new releases of org-netbeans-insane available, but I would be very surprised if they were able to be updated to be compliant with the Java 9+ module system. It seems like what that library is doing fundamentally requires access to JDK-internal classes and data structures.
If we think the test in script-security would be valuable for detecting memory leaks in the future, then maybe we could just add an assumption so it only runs on JDK 8? Otherwise, I think we'd just have to remove the tests and eventually MemoryAssert itself.
vilacides was opened as minor so didn't get our attention. From the stack trace it looks like issue somewhere in jenkins-test-harness. We are going to investigate as whats goin in there.
Adrien Lecharpentier
added a comment - vivek I changed the component here as well. Sorry for the wrong assignment.
Adrien Lecharpentier
added a comment - vivek I changed the component here as well. Sorry for the wrong assignment. alecharp once you've run the test, could you please make sure to update the Google document with the validated version? Thanks!
Adrien Lecharpentier
added a comment - The problem is still really update to date and is only about the tests. At first, I thought it was ok, but I was wrong.
As dnusbaum said, this is because of the post-GC validation, done using the NetBeans Insane Library. I tried to update it, with no luck, as expected due to the release date.
It seems that the plugin is compatible with Java 11, but not its tests (because of this library).
I don't know how to proceed from there.
Adrien Lecharpentier
added a comment - The problem is still really update to date and is only about the tests. At first, I thought it was ok, but I was wrong.
As dnusbaum said, this is because of the post-GC validation, done using the NetBeans Insane Library. I tried to update it, with no luck, as expected due to the release date.
It seems that the plugin is compatible with Java 11, but not its tests (because of this library).
I don't know how to proceed from there. alecharp My recommendation would be to add an Assume.isTrue(isRunningOnJDK8OrOlder()) to methods in MemoryAssert so that it only runs on older JDKs since it is unlikely that such code can ever be made to work after the module-related changes in JDK 9, but the tests themselves may be useful in some cases. Other than that I think our only option would be to delete the class (and then the tests downstream after updating parent poms), which seems fine if it is not possible to make the assumptions work correctly.
Adrien Lecharpentier
added a comment - Filled as PR-238 The fix has been integrated into the master branch in https://github.com/jenkinsci/script-security-plugin/commit/0b24dde6270a59f4e5782cfacc10c681c9e50912 , but it has not been released yet
Isa Vilacides
added a comment - dnusbaum abayer are you taking it from here to get it released? I just released script-security 1.55 with the fix for the PCT issues seen on Java 11.
vivek this is a GA blocker, any plans for working on this?