Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-55303

[PCT] check script-security latest (jenkins-test-harness - Using JDK internal classes )

    XMLWordPrintable

Details

    • 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

          Activity

            vilacides Isa Vilacides added a comment -

            vivek this is a GA blocker, any plans for working on this?

            vilacides Isa Vilacides added a comment - vivek this is a GA blocker, any plans for working on this?
            abayer Andrew Bayer added a comment -

            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?

            abayer Andrew Bayer added a comment - 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 ?

            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.

            alecharp 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.
            dnusbaum Devin Nusbaum added a comment -

            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.

            dnusbaum Devin Nusbaum added a comment - 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.
            vivek Vivek Pandey added a comment -

            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.

            vivek Vivek Pandey added a comment - 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.

            vivek I changed the component here as well. Sorry for the wrong assignment.

            alecharp 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!

            Cf. https://docs.google.com/document/d/1oluVrNVpQhXCIwW9CYVm09Y1vPc3H77d3q92LrzcpDw/edit?disco=AAAACkkgfSE

            batmat Baptiste Mathus added a comment - alecharp once you've run the test, could you please make sure to update the Google document with the validated version? Thanks! Cf. https://docs.google.com/document/d/1oluVrNVpQhXCIwW9CYVm09Y1vPc3H77d3q92LrzcpDw/edit?disco=AAAACkkgfSE

            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 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.
            dnusbaum Devin Nusbaum added a comment - - edited

            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.

            dnusbaum Devin Nusbaum added a comment - - edited 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.

            Filled as PR-238

            alecharp Adrien Lecharpentier added a comment - Filled as PR-238
            oleg_nenashev Oleg Nenashev added a comment -

            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

            oleg_nenashev Oleg Nenashev added a comment - 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
            vilacides Isa Vilacides added a comment -

            dnusbaum abayer are you taking it from here to get it released?

            vilacides Isa Vilacides added a comment - dnusbaum abayer are you taking it from here to get it released?
            dnusbaum Devin Nusbaum added a comment -

            I just released script-security 1.55 with the fix for the PCT issues seen on Java 11.

            dnusbaum Devin Nusbaum added a comment - I just released script-security 1.55 with the fix for the PCT issues seen on Java 11.
            vivek Vivek Pandey added a comment -

            Awesome, thanks dnusbaum!

            vivek Vivek Pandey added a comment - Awesome, thanks dnusbaum !

            Thanks a lot everyone!

            batmat Baptiste Mathus added a comment - Thanks a lot everyone!

            People

              alecharp Adrien Lecharpentier
              alecharp Adrien Lecharpentier
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: