Details
Description
The archiving artifacts didn't work before jenkins 1.486 due to https://issues.jenkins-ci.org/browse/JENKINS-13202 I believe. The exception was the same.
But since ~1.486 the build just hangs on artifacts archiving, and only the following can be found in logs:
===========
INFO: test-ia64 #6 main build action completed: SUCCESS
Oct 31, 2012 2:10:04 PM hudson.remoting.SynchronousCommandTransport$ReaderThread run
SEVERE: I/O error in channel ca-build26
java.io.IOException: Unexpected termination of the channel
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.Command.readFrom(Command.java:90)
at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
==================
The build is marked as successful after manually build abortion, and an exception can be seen in the console.
The job is simple: 'echo TEST > ${WORKSPACE}/1.txt', and archive 1.txt then.
thead dump from master and slave is attached
Attachments
Issue Links
- depends on
-
JENKINS-14351 Outdated JRuby libs
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
- is related to
-
-
- Closed
-
-
JENKINS-24521 Update jna from 3.3.0-jenkins to 4.1.0 (or newer)
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
Activity
By the way anyone using proprietary or unusual platforms should not expect that Jenkins core developers will be able to reproduce their problems. Debug it yourself and file a pull request if you want a prompt fix.
@jglick: What if we'd provide access to an affected machine, either via ssh or direct access? Would some core developer be willing to tackle the problem in that case?
Oliver Bock
added a comment -
By the way anyone using proprietary or unusual platforms should not expect that Jenkins core developers will be able to reproduce their problems. Debug it yourself and file a pull request if you want a prompt fix.
@jglick: What if we'd provide access to an affected machine, either via ssh or direct access? Would some core developer be willing to tackle the problem in that case? @brevilo: yes this is a possibility. I cannot personally commit to finding the time for it at the moment, I am afraid.
Let me see if I understand the flow of logic. It is trying to resolve a symlink, correct? Util.java -> resolveSymlink.
First, it tries calling 'java.nio.file.Files' in Java7. If that isn't available, it tries to load this library:
https://kenai.com/projects/jna-posix/sources/mercurial/show/src/org/jruby/ext/posix?rev=59
If that fails, it tries to load this library:
https://github.com/jnr/jnr-posix/tree/master/src/main/java/jnr/posix
All three fail, possibly due to using a non-Oracle Java runtime? The key section in the logs being:
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
at org.jruby.ext.posix.POSIXFactory.loadLibC(POSIXFactory.java:96)
I suppose that makes this a duplicate of JENKINS-13202?
Jenkins has been updated to use JNA 4.1: JENKINS-24521
Please try again, since this fixes many native library issues.
The fix will be in Jenkins 1.586 and higher.
Craig Rodrigues
added a comment - - edited Jenkins has been updated to use JNA 4.1: JENKINS-24521
Please try again, since this fixes many native library issues.
The fix will be in Jenkins 1.586 and higher. 
@makr: newer versions of Jenkins on Java 7+ will not exhibit this error because they use a different code path.
By the way anyone using proprietary or unusual platforms should not expect that Jenkins core developers will be able to reproduce their problems. Debug it yourself and file a pull request if you want a prompt fix.