Loading...

Type: Bug
Resolution: Fixed
Priority: Major
Component/s: core
Labels:
None

Similar Issues:

Show
Released As:
2.449

I'm experiencing this problem with pipeline-maven-plugin when it is running 'Generated Artifacts Publisher' when running maven on a z/OS agent (line numbers are as of Jenkins version 2.426.2):

ERROR: [withMaven] WARNING Exception executing Maven reporter 'Generated Artifacts Publisher' / org.jenkinsci.plugins.pipeline.maven.publishers.GeneratedArtifactsPublisher. Please report a bug associated for the component 'pipeline-maven-plugin' at https://issues.jenkins-ci.org 
 java.io.IOException: Exception archiving { map content removed }
 	at org.jenkinsci.plugins.pipeline.maven.publishers.GeneratedArtifactsPublisher.process(GeneratedArtifactsPublisher.java:145)
 	at org.jenkinsci.plugins.pipeline.maven.MavenSpyLogProcessor.processMavenSpyLogs(MavenSpyLogProcessor.java:172)
 	at org.jenkinsci.plugins.pipeline.maven.WithMavenStepExecution2$WithMavenStepExecutionCallBack.finished(WithMavenStepExecution2.java:1359)
 	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
 	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
 	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 	at java.base/java.lang.Thread.run(Thread.java:840)
 Caused by: java.io.IOException: Failed to extract /path removed/transfer of 8 files
 	at hudson.FilePath.readFromTar(FilePath.java:3068)
 	at hudson.FilePath.copyRecursiveTo(FilePath.java:2828)
 	at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:73)
 	at org.jenkinsci.plugins.pipeline.maven.publishers.GeneratedArtifactsPublisher.process(GeneratedArtifactsPublisher.java:143)
 	... 9 more
 Caused by: java.nio.charset.UnmappableCharacterException: Input length = 1
 	at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275)
 	at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:820)
 	at org.apache.commons.compress.archivers.zip.NioZipEncoding.decode(NioZipEncoding.java:130)
 	at org.apache.commons.compress.archivers.tar.TarUtils.parseName(TarUtils.java:524)
 	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeaderUnwrapped(TarArchiveEntry.java:1543)
 	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1531)
 	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.<init>(TarArchiveEntry.java:553)
 	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:464)
 	at hudson.FilePath.readFromTar(FilePath.java:3043)
 	... 12 more

Code review turned out that this is most likely a problem in hudson.FilePath#copyRecursiveTo implementation (line numbers are as of Jenkins version 2.440):

Assumption is that the remote part is the agent with a default character set of CP1047 (EBCDIC) and local is a Windows or Linux with something ASCII/UTF-8 based.
At FilePath.java#L2864 CopyRecursiveRemoteToLocal is instantiated and effectively CopyRecursiveRemoteToLocal#invoke is executed at the agent:
1. Calling FilePath#writeToTar() which effectively calls hudson.util.io.ArchiverFactory.TarArchiverFactory#create() which instantiates and returns a TarArchiver.
2. The TarArchiver instatiates in its constructor at TarArchiver.java#L53 a TarArchiveOutputStream with constructor org.apache.commons.compress.archivers.tar.TarArchiveOutputStream#TarArchiveOutputStream(final OutputStream os). Using this constructor results at TarArchiveOutputStream.java#L221 in initializing member zipEncoding from call to ZipEncodingHelper.getZipEncoding(null).
3. ZipEncodingHelper#getZipEncoding(null) returns effectively the Charset.defaultCharset() being wrapped into a NioZipEncoding object which is stored in TarArchiveOutputStream#zipEncoding.
4. TarArchiveOutputStream.java#zipEncoding is used then to encode names written into the tar archive at TarArchiveOutputStream.java#handleLongName(), TarArchiveOutputStream#putArchiveEntry(), and TarArchiveOutputStream.java#L614
So per above file names are written to the tar archive with agents default character set which is CP1047 in our case.
At controller side which reads the tar stream from FilePath.java#L2866 calling FilePath#readFromTar() which instantiates TarArchiveInputStream. That has a zipEncoding member, too. It is initialized at TarArchiveInputStream.java#L211 the same way as TarArchiveOutputStream's zipEncoding member. However, since this is executed at the controller it receives whatever the default character set is there.
Due to the mismatch of character sets used for writing and reading file names in tar stream the reading fails.

I suspect that JENKINS-18558 is related to this issue.

is related to

JENKINS-18558 FilePath's copyRecursiveTo doesn't handle Chinese characters

Open

links to

https://github.com/jenkinsci/jenkins/pull/8860

Details

Description

Attachments

Issue Links

Activity

People

Dates