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

Illegal reflective access by JNR to FileDescriptor#fd

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • core
    • JDK 9, Jenkins 2.60.3 as described in my lts-with-plugins docker instance
    • 2.93

    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

            ndeloof Nicolas De Loof added a comment - see https://github.com/jnr/jnr-posix/issues/110  
            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.

            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.

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

            batmat Baptiste Mathus added a comment - dnusbaum 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!
            dnusbaum Devin Nusbaum added a comment -

            batmat 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.

            dnusbaum Devin Nusbaum added a comment - batmat 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.
            basil Basil Crow added a comment -

            This particular stack trace was fixed in jenkinsci/jenkins#3135. If you encounter any new illegal reflective access errors relating to JNR, please open a new Jira ticket with the new stack trace.

            basil Basil Crow added a comment - This particular stack trace was fixed in jenkinsci/jenkins#3135 . If you encounter any new illegal reflective access errors relating to JNR, please open a new Jira ticket with the new stack trace.

            People

              Unassigned Unassigned
              markewaite Mark Waite
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: