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

FilePath.copyRecursiveTo() fails for local to slave copy when slave is on AIX, HP-UX, or Linux s/390

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • Hudson 1.386 running as system service on SUSE Linux Enterprise 10 x86_64. Configured multiple slaves, affected are AIX 5.2 - 7.1 on ppc64, HP-UX 11.11 - 11.31 on PA-RISC and 11.23 - 11.31 on Itanium2, SUSE and Redhat Linuxes on s/390.

      I intended to use the CopyArtifact plugin and split a build task so that I just checkout on the master and then copy the sources over to the build machines. This works for all JNA supported environments, e.g. Windows, Solaris, and Linux on ix86/x86_64, but fails with the stack trace below (taken from one of the AIXes) on all other machines...

      ERROR: Failed to copy artifacts from Local_WIR_Build with filter: **
      hudson.util.IOException2: java.lang.UnsatisfiedLinkError: jnidispatch (/com/sun/jna/aix-ppc64/libjnidispatch.a) not found in resource path
      at hudson.FilePath.copyRecursiveTo(FilePath.java:1474)
      at hudson.FilePath.copyRecursiveTo(FilePath.java:1399)
      at hudson.plugins.copyartifact.FilePathCopyMethod.init(FilePathCopyMethod.java:56)
      at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:190)
      at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:168)
      at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
      at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:603)
      at hudson.model.Build$RunnerImpl.build(Build.java:172)
      at hudson.model.Build$RunnerImpl.doRun(Build.java:137)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:417)
      at hudson.model.Run.run(Run.java:1325)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:139)
      Caused by: java.util.concurrent.ExecutionException: java.lang.UnsatisfiedLinkError: jnidispatch (/com/sun/jna/aix-ppc64/libjnidispatch.a) not found in resource path
      at hudson.remoting.Channel$2.adapt(Channel.java:662)
      at hudson.remoting.Channel$2.adapt(Channel.java:657)
      at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)
      at hudson.FilePath.copyRecursiveTo(FilePath.java:1472)
      ... 13 more
      Caused by: java.lang.UnsatisfiedLinkError: jnidispatch (/com/sun/jna/aix-ppc64/libjnidispatch.a) not found in resource path
      at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:703)
      at com.sun.jna.Native.loadNativeLibrary(Native.java:680)
      at com.sun.jna.Native.<clinit>(Native.java:108)
      at java.lang.J9VMInternals.initializeImpl(Native Method)
      at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
      at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:105)
      at java.lang.J9VMInternals.initializeImpl(Native Method)
      at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
      at hudson.FilePath.readFromTar(FilePath.java:1570)
      at hudson.FilePath.access$100(FilePath.java:159)
      at hudson.FilePath$32.invoke(FilePath.java:1463)
      at hudson.FilePath$32.invoke(FilePath.java:1460)
      at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1899)
      at hudson.remoting.UserRequest.perform(UserRequest.java:114)
      at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      at hudson.remoting.Request$2.run(Request.java:270)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:452)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
      at java.util.concurrent.FutureTask.run(FutureTask.java:149)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:735)

          [JENKINS-8155] FilePath.copyRecursiveTo() fails for local to slave copy when slave is on AIX, HP-UX, or Linux s/390

          Matthias Kraft created issue -

          Looking through the stacktrace I stumbled over hudson.FilePath.readFromTar(FilePath.java:1570) and looking in the source you see it ignores NoClassDefFoundError, but not UnsatisfiedLinkError.

          This could be the quick fix, I guess. The real solution might be to place all LIBC usage into a wrapper class, that invokes the respective command line tools, if LIBC is not available.

          Matthias Kraft added a comment - Looking through the stacktrace I stumbled over hudson.FilePath.readFromTar(FilePath.java:1570) and looking in the source you see it ignores NoClassDefFoundError, but not UnsatisfiedLinkError. This could be the quick fix, I guess. The real solution might be to place all LIBC usage into a wrapper class, that invokes the respective command line tools, if LIBC is not available.

          Romain Seguy added a comment -

          I also add the copy-to-slave plugin as a component of this issue as it's also impacted. Cf. this thread: https://groups.google.com/group/hudson-users/browse_thread/thread/9bc7b0c954811bd5?hl=fr

          Romain Seguy added a comment - I also add the copy-to-slave plugin as a component of this issue as it's also impacted. Cf. this thread: https://groups.google.com/group/hudson-users/browse_thread/thread/9bc7b0c954811bd5?hl=fr
          Romain Seguy made changes -
          Component/s New: copy-to-slave [ 15691 ]

          Romain Seguy added a comment -

          I think we can get around this issue by (1) catching the exception as mentionned by makr and (2) trying to run, instead of glibc's chmod() function, its Ant equivalent (which finally delegates to the chmod command line utility).

          Do you agree with that Alan? If yes I'll go ahead and will patch that in the days to come (once I'll be 100% sure where to commit the code actually )

          Romain Seguy added a comment - I think we can get around this issue by (1) catching the exception as mentionned by makr and (2) trying to run, instead of glibc's chmod() function, its Ant equivalent (which finally delegates to the chmod command line utility). Do you agree with that Alan? If yes I'll go ahead and will patch that in the days to come (once I'll be 100% sure where to commit the code actually )

          Alan Harder added a comment -

          sure rseguy.. I assigned myself as I figured I could put in the minimal fix of catching the exception, but if you'll go further please takeover and reassign..

          Alan Harder added a comment - sure rseguy.. I assigned myself as I figured I could put in the minimal fix of catching the exception, but if you'll go further please takeover and reassign..
          Romain Seguy made changes -
          Assignee Original: Alan Harder [ mindless ] New: Romain Seguy [ rseguy ]
          Romain Seguy made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Alan Harder made changes -
          Link New: This issue is duplicated by JENKINS-8250 [ JENKINS-8250 ]

          Romain Seguy added a comment -

          Fixed. Should be delivered to 1.390 or 1.391.

          Romain Seguy added a comment - Fixed. Should be delivered to 1.390 or 1.391.
          Romain Seguy made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]

            rseguy Romain Seguy
            makr Matthias Kraft
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: