[JENKINS-28016] Option to block JNA from being used on a slave

[timja]

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}.

---

Originally reported by jglick, imported from: Option to block JNA from being used on a slave

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

[Originally related to: JENKINS-10582]

[timja]

[Originally related to: JENKINS-27990]