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

Archiving artifiacts fails with java.io.IOException: Truncated TAR archive

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • Jenkins 1.610 (currently most recent), Ubuntu LTS 14.04 64-bit master, SLES11 64-bit slave

      The 'archive artifacts' step of some build jobs have recently started failing with the following trace:

      Archiving artifacts
      ERROR: Failed to archive artifacts: **/*.deb, **/*.changes, **/*.rpm, **/*.egg
      java.io.IOException: Failed to extract /srv/user_name/.jenkins/workspace/SomeProject/distro/sles11_64/servertype/build/transfer of 4 files
      	at hudson.FilePath.readFromTar(FilePath.java:2299)
      	at hudson.FilePath.copyRecursiveTo(FilePath.java:2208)
      	at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)
      	at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:219)
      	at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
      	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721)
      	at hudson.model.Build$BuildExecution.post2(Build.java:183)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670)
      	at hudson.model.Run.execute(Run.java:1766)
      	at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
      	at hudson.model.ResourceController.execute(ResourceController.java:98)
      	at hudson.model.Executor.run(Executor.java:374)
      Caused by: java.io.IOException: Truncated TAR archive
      	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.read(TarArchiveInputStream.java:614)
      	at java.io.InputStream.read(InputStream.java:101)
      	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
      	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
      	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
      	at hudson.util.IOUtils.copy(IOUtils.java:40)
      	at hudson.FilePath.readFromTar(FilePath.java:2289)
      	... 13 more
      Build step 'Archive the artifacts' changed build result to FAILURE
      

      It seems that the jobs on the slaves succeeded, but the master fails:

      Apr 20, 2015 11:15:14 AM hudson.model.Run execute
      INFO: SomeProject/distro=sles11_64,servertype=build #12159 main build action completed: SUCCESS
      [... more slave SUCCESS reports ...]
      Apr 20, 2015 11:16:16 AM hudson.model.Run execute
      INFO: SomeProject #12159 main build action completed: FAILURE
      

      The master and slave logs do not show me any other errors.

      This failure occurs just for some of the slave jobs in this matrix build job. Within a specific job, this fails consistently for the same slaves, but across jobs the slaves that fail vary.

      There are no obvious resource issues; both disk space and memory usage seem to be fine.

          [JENKINS-28013] Archiving artifiacts fails with java.io.IOException: Truncated TAR archive

          Frank Stiller added a comment -

          The problem is not coming up on every build. I started building 5 artifacts. 3 of them failed. Have now rolled back to 1.609 as they had the exact same configuration

          Frank Stiller added a comment - The problem is not coming up on every build. I started building 5 artifacts. 3 of them failed. Have now rolled back to 1.609 as they had the exact same configuration

          Same problem. Reverted to 1.609 solved it.

          Fredrik Duprez added a comment - Same problem. Reverted to 1.609 solved it.

          Oleg Nenashev added a comment -

          I was unable to reproduce the issue on Java 6/7 and remote Windows/Ubuntu/Mac slaves. Massive load experiments didn't help as well.

          Does anybody see the issue on these Java versions? Probably, it could be something specific to Java8 or to the remoting behavior.

          Oleg Nenashev added a comment - I was unable to reproduce the issue on Java 6/7 and remote Windows/Ubuntu/Mac slaves. Massive load experiments didn't help as well. Does anybody see the issue on these Java versions? Probably, it could be something specific to Java8 or to the remoting behavior.

          Ayako Baba added a comment -

          Same problem.

          java version "1.8.0_05"
          Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
          Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

          Ayako Baba added a comment - Same problem. java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

          Oleg, positive. SLES 11, java 1.7.0_45-b18 - the problem appears. Not on every job though. But if the job is "cursed" then "Truncated TAR archive" on every its build.

          Andrey Regentov added a comment - Oleg, positive. SLES 11, java 1.7.0_45-b18 - the problem appears. Not on every job though. But if the job is "cursed" then "Truncated TAR archive" on every its build.

          Oleg Nenashev added a comment -

          The issue has been caused by a binary stream corruption in Tar archiving procedures.
          https://github.com/jenkinsci/jenkins/pull/1667 has been created to revert the change

          Oleg Nenashev added a comment - The issue has been caused by a binary stream corruption in Tar archiving procedures. https://github.com/jenkinsci/jenkins/pull/1667 has been created to revert the change

          I am running Java 8 on both master and slave (both Linux), and get the problem.

          From the comments on https://github.com/jenkinsci/jenkins/pull/1667, it looks the maintainers can now reproduce the problem.

          Matthew Webber added a comment - I am running Java 8 on both master and slave (both Linux), and get the problem. From the comments on https://github.com/jenkinsci/jenkins/pull/1667 , it looks the maintainers can now reproduce the problem.

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/pom.xml
          core/src/main/java/hudson/FilePath.java
          core/src/main/java/hudson/org/apache/tools/tar/TarInputStream.java
          core/src/main/java/hudson/org/apache/tools/tar/TarOutputStream.java
          core/src/main/java/hudson/util/io/TarArchiver.java
          http://jenkins-ci.org/commit/jenkins/ca21c65bf2538982126bd465eb70840071a61e4e
          Log:
          Merge pull request #1667 from oleg-nenashev/JENKINS-10629-FIX

          [JENKINS-28013,JENKINS-28012] - Revert changes for JENKINS-10629

          Compare: https://github.com/jenkinsci/jenkins/compare/8c94920973c4...ca21c65bf253

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/pom.xml core/src/main/java/hudson/FilePath.java core/src/main/java/hudson/org/apache/tools/tar/TarInputStream.java core/src/main/java/hudson/org/apache/tools/tar/TarOutputStream.java core/src/main/java/hudson/util/io/TarArchiver.java http://jenkins-ci.org/commit/jenkins/ca21c65bf2538982126bd465eb70840071a61e4e Log: Merge pull request #1667 from oleg-nenashev/ JENKINS-10629 -FIX [JENKINS-28013,JENKINS-28012] - Revert changes for JENKINS-10629 Compare: https://github.com/jenkinsci/jenkins/compare/8c94920973c4...ca21c65bf253

          Daniel Beck added a comment -

          Resolved by reverting the fix for JENKINS-10629.

          Daniel Beck added a comment - Resolved by reverting the fix for JENKINS-10629 .

          Alojzij added a comment -

          Just an information, that others might find it useful.

          We had a similar stack trace, but the cause was Windows Defender, that apparently deleted the file after it was accessed for archiving. The fix was, that we had to disable "Real-time protection".

          Alojzij added a comment - Just an information, that others might find it useful. We had a similar stack trace, but the cause was Windows Defender, that apparently deleted the file after it was accessed for archiving. The fix was, that we had to disable "Real-time protection".

            oleg_nenashev Oleg Nenashev
            syzzer Steffan Karger
            Votes:
            34 Vote for this issue
            Watchers:
            52 Start watching this issue

              Created:
              Updated:
              Resolved: