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

Illegal reflective access by jenkins.slaves.StandardOutputSwapper$ChannelSwapper to constructor java.io.FileDescriptor(int)

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • core
    • Jenkins 2.263.4
      RH7 Linux, no container (slaves and master)
      remoting 4.5
      openJDK jdk-11.0.9.1+1 on slaves and master
      (openJDK jdk8u275-b01 for crosscheck on one slave)

    Description

      On start of a slave using openJDK jdk-11.0.9.1+1 on slaves and master I get in the log:

      --------------

      <===[JENKINS REMOTING CAPACITY]===>channel started
      Remoting version: 4.5
      This is a Unix agent
      WARNING: An illegal reflective access operation has occurred
      WARNING: Illegal reflective access by jenkins.slaves.StandardOutputSwapper$ChannelSwapper to constructor java.io.FileDescriptor(int)
      WARNING: Please consider reporting this to the maintainers of jenkins.slaves.StandardOutputSwapper$ChannelSwapper
      WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
      WARNING: All illegal access operations will be denied in a future release
      Evacuated stdout
      [StartupTrigger] - Scanning jobs for node ullteb106

      --------------

      The bold warning makes me a little bit nervous....

      All these warnings are not present, if I use openJDK jdk8u275-b01 instead. (Everything else unchanged)

      There is a similar report referring to Windows and (Sun) JDK9: https://issues.jenkins.io/browse/JENKINS-46631
      And on JDK11, but referring to "after installing the selenium plugin" https://issues.jenkins.io/browse/JENKINS-64831

      (We DON'T have this plugin installed)

      I'm running Jenkins with JDK11, because in my understanding the switch is pending; I'm using openJDK because Sun/Oracle would need a license in my understanding.

      Attachments

        Issue Links

          Activity

            nkjensen Niels Kristian Jensen added a comment - - edited

            Also seen with Remoting version: 4.13.2, from the log:

            openjdk 11.0.15 2022-04-19
            OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.18.04.1)
            OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.18.04.1, mixed mode, sharing)

            running master "Jenkins 2.346.1"

            Tim noted that the logs are harmless - perhaps this is just to be ignored?

            nkjensen Niels Kristian Jensen added a comment - - edited Also seen with Remoting version: 4.13.2, from the log: openjdk 11.0.15 2022-04-19 OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.18.04.1) OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.18.04.1, mixed mode, sharing) running master "Jenkins 2.346.1" Tim noted that the logs are harmless - perhaps this is just to be ignored?
            msymons Mark Symons added a comment -

            Issue still affect 2.346.1 using Remoting version: 4.13.2

            msymons Mark Symons added a comment - Issue still affect 2.346.1 using Remoting version: 4.13.2
            jglick Jesse Glick added a comment -

            I gave some suggestions in JENKINS-64831.

            jglick Jesse Glick added a comment - I gave some suggestions in JENKINS-64831 .
            basil Basil Crow added a comment - - edited

            The code in question could be reworked to call jnr-posix's JavaLibCHelper.toFileDescriptor, but that also prints a reflective access warning as described in jnr/jnr-posix#110. The comments to that issue describe one possible workaround (using JNI), but really the root of the problem is that this use case just isn't supported by the Java Platform. StandardOutputSwapper itself only seems to exist as Kohsuke's solution to a stream integrity problem encountered years ago. It might be worth reconsidering that use case and possibly redesigning the subsystem so that this problem (and therefore the use case for doing file descriptor manipulation from Java) is avoided.

            basil Basil Crow added a comment - - edited The code in question could be reworked to call jnr-posix 's JavaLibCHelper.toFileDescriptor , but that also prints a reflective access warning as described in jnr/jnr-posix#110 . The comments to that issue describe one possible workaround (using JNI), but really the root of the problem is that this use case just isn't supported by the Java Platform. StandardOutputSwapper itself only seems to exist as Kohsuke's solution to a stream integrity problem encountered years ago. It might be worth reconsidering that use case and possibly redesigning the subsystem so that this problem (and therefore the use case for doing file descriptor manipulation from Java) is avoided.
            timja Tim Jacomb added a comment -

            > The bold warning makes me a little bit nervous....

            These logs are harmless on java 11 so don't worry about it.

            Thanks for the report

            timja Tim Jacomb added a comment - > The bold warning makes me a little bit nervous.... These logs are harmless on java 11 so don't worry about it. Thanks for the report

            People

              Unassigned Unassigned
              martinjost Martin Jost
              Votes:
              3 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated: