-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major
-
Component/s: core
-
Environment:ref. ZD-21778
A user of 1.554.2 reported an error apparently similar to JENKINS-10582 causing builds to often fail in cleanup:
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:722) at hudson.Launcher$RemoteLauncher.kill(Launcher.java:912) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:608) at ...
with a HotSpot crash mentioning JNA:
EXCEPTION_ACCESS_VIOLATION ... j com.sun.jna.Native.free(J)V+0 j com.sun.jna.Memory.free(J)V+1 j com.sun.jna.Memory.dispose()V+4 j com.sun.jna.Memory.finalize()V+1 v ~StubRoutines::call_stub j java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V+0 J java.lang.ref.Finalizer$FinalizerThread.run()V v ~StubRoutines::call_stub
The problem disappeared when passing -Dhudson.util.ProcessTree.disable=true to Jenkins. However this was just luck: there was no indication from either error message that ProcessTree was involved, as opposed to some other code running on the slave that happened to use JNA. (file deletion, SVNKit, etc.)
To narrow down problems to either JNA or a JRE bug, it would be better to have a single option that stops a given slave (or any slave, or even the master too) from using JNA in any way. Perhaps this could be enforced in the slave class loader by refusing to transfer com/sun/jna/*/*.{so,dll,jnalib}.
- is related to
-
JENKINS-27990 Startup fails on s390x/Linux - java.lang.UnsatisfiedLinkError: jnidispatch
-
- Closed
-
-
-
- Closed
-
