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

[JDK9] Illegal reflective access from FilePath

    Details

    • Similar Issues:

      Description

      While exploring Jenkins 2.60.3 on Oracle Java 9 build 181 (pre-release), it reports illegal access exceptions and warns that a future release of Java 9 will forbid illegal access.

      A partial stack trace shows:

      WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/var/jenkins_home/war/WEB-INF/lib/jnr-posix-3.0.1.jar) to field java.io.FileDescriptor.fd
              at jnr.posix.JavaLibCHelper.<clinit>(JavaLibCHelper.java:118)
              at jnr.posix.BaseNativePOSIX.<init>(BaseNativePOSIX.java:38)
              at jnr.posix.LinuxPOSIX.<init>(LinuxPOSIX.java:20)
              at jnr.posix.POSIXFactory.loadLinuxPOSIX(POSIXFactory.java:95)
              at jnr.posix.POSIXFactory.loadNativePOSIX(POSIXFactory.java:69)
              at jnr.posix.POSIXFactory.loadPOSIX(POSIXFactory.java:38)
              at jnr.posix.LazyPOSIX.loadPOSIX(LazyPOSIX.java:33)
              at jnr.posix.LazyPOSIX.posix(LazyPOSIX.java:29)
              at jnr.posix.LazyPOSIX.chmod(LazyPOSIX.java:55)
              at hudson.FilePath._chmod(FilePath.java:1611)
              at hudson.FilePath.access$1500(FilePath.java:197)
              at hudson.FilePath$29.invoke(FilePath.java:1596)
              at hudson.FilePath$29.invoke(FilePath.java:1592)
              at hudson.FilePath.act(FilePath.java:998)
              at hudson.FilePath.act(FilePath.java:976)
              at hudson.FilePath.chmod(FilePath.java:1592)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createSshKeyFile(CliGitAPIImpl.java:1662)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1578)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1561)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1552)                                          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2676)
              at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:640)                                                                     at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:599)
              at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:391)                                                                                       at hudson.scm.SCM.poll(SCM.java:408)
              at hudson.model.AbstractProject._poll(AbstractProject.java:1458)                                                                                at hudson.model.AbstractProject.poll(AbstractProject.java:1361)
              at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:594)                                                                            at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:640)
              at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119)                                                       at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
              at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)                                                                   

      Appears to be the FilePath call to LazyPOSIX.chmod().

        Attachments

          Issue Links

            Activity

            Hide
            dnusbaum Devin Nusbaum added a comment -

            Baptiste Mathus I think that before https://github.com/jenkinsci/jenkins/pull/3135, you would get this error just from starting Jenkins, whereas now you would only get it if methods are actively called that use particular methods inside of PosixAPI#jnr, but I'm not sure what those methods are or whether they are called in normal Jenkins usage and so still a problem. Once we know the answer to that, I think we could close this issue and open new ones as needed.

            I don't think there is any way for the jnr-posix library to become fully compliant with reflective access without changes to Java APIs, see https://github.com/jnr/jnr-posix/issues/110 as an example, so I think the long-term approach would be to detach the library and rewrite places that need it to use pure Java APIs where possible to reduce our dependency on jnr-posix. See JENKINS-46725 (which I think should be reopened)/https://github.com/jenkinsci/jenkins/pull/3511 for more info. IIRC the majority of uses are just to get the current Process ID, which was added in Java 9 to the java.lang.Process API, so with some kind of new API/multi-release JAR to use the Process API on Java 9+ with a fallback on older versions of Java we might be able to get rid of most of the uses. Part of the issue here is that we expose the jnr-posix API directly in Jenkins core, so plugins can use anything it provides.

            With backwards compatibility in mind, we probably need to investigate all usages of PosixAPI in plugins to understand what would need to be switched. We should also check which APIs that we currently use throw reflective access exceptions, since if they aren't thrown for any of the calls in core or major plugins than detaching the library is not as urgent.

            Show
            dnusbaum Devin Nusbaum added a comment - Baptiste Mathus I think that before https://github.com/jenkinsci/jenkins/pull/3135 , you would get this error just from starting Jenkins, whereas now you would only get it if methods are actively called that use particular methods inside of PosixAPI#jnr , but I'm not sure what those methods are or whether they are called in normal Jenkins usage and so still a problem. Once we know the answer to that, I think we could close this issue and open new ones as needed. I don't think there is any way for the jnr-posix library to become fully compliant with reflective access without changes to Java APIs, see https://github.com/jnr/jnr-posix/issues/110 as an example, so I think the long-term approach would be to detach the library and rewrite places that need it to use pure Java APIs where possible to reduce our dependency on jnr-posix. See JENKINS-46725  (which I think should be reopened)/ https://github.com/jenkinsci/jenkins/pull/3511 for more info. IIRC the majority of uses are just to get the current Process ID, which was added in Java 9 to the java.lang.Process API, so with some kind of new API/multi-release JAR to use the Process API on Java 9+ with a fallback on older versions of Java we might be able to get rid of most of the uses. Part of the issue here is that we expose the jnr-posix API directly in Jenkins core , so plugins can use anything it provides. With backwards compatibility in mind, we probably need to investigate all usages of PosixAPI in plugins to understand what would need to be switched. We should also check which APIs that we currently use throw reflective access exceptions, since if they aren't thrown for any of the calls in core or major plugins than detaching the library is not as urgent.
            Hide
            batmat Baptiste Mathus added a comment -

            Devin Nusbaum IIUC, you're saying this is actually fixed now?
            Can we close somehow this ticket? Given you've worked in some of these, I'd appreciate some proposal/guidance here for the next steps: like should we even care and close this JIRA, close this one and file something more specific to fix the remainder issue, etc?

            Thanks for your help!

            Show
            batmat Baptiste Mathus added a comment - Devin Nusbaum IIUC, you're saying this is actually fixed now? Can we close somehow this ticket? Given you've worked in some of these, I'd appreciate some proposal/guidance here for the next steps: like should we even care and close this JIRA, close this one and file something more specific to fix the remainder issue, etc? Thanks for your help!
            Hide
            dnusbaum Devin Nusbaum added a comment -

            This call should no longer happen in a default installation after Jenkins 2.93 which contains https://github.com/jenkinsci/jenkins/pull/3135 (part of JENKINS-36088) unless the user has explicitly enabled the native mode via system property.

            Here is the code in question, which now defaults to the Java implementation. Even though it shouldn't affect users by default anymore, as I mentioned on JENKINS-46725 I don't think there is any obstacle to removing the native option for good.

            Show
            dnusbaum Devin Nusbaum added a comment - This call should no longer happen in a default installation after Jenkins 2.93 which contains https://github.com/jenkinsci/jenkins/pull/3135  (part of  JENKINS-36088 ) unless the user has explicitly enabled the native mode via system property. Here  is the code in question, which now defaults to the Java implementation. Even though it shouldn't affect users by default anymore, as I mentioned on JENKINS-46725 I don't think there is any obstacle to removing the native option for good.
            Show
            ndeloof Nicolas De Loof added a comment - see https://github.com/jnr/jnr-posix/issues/110  

              People

              • Assignee:
                Unassigned
                Reporter:
                markewaite Mark Waite
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: