Jenkins throwing java.lang.StackOverflowError -- Not just on unstash

Question

Update July 31, 2019
The error sometimes happens before the unstash call, but always on the same server. In an effort to see if the problem was caused by unstash working in a directory where it needed to overwrite files, I cleaned the directory -- but the problem still happened. This time the output began (transcribed, any typos are my fault):

Running on my_agent in C:/Jenkins/workspace/script_name
. . .
Running in D:\mydir
[Pipeline] {
[Pipeline] bat
[mydir] Running batch script
D:\mydir> dir .
<output of dir command>
[Pipeline] End of Pipeline
java.lang.StackOverflowError
    at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:115)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:778)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
etc.

It did not reach the unstash call, but still got the same error.
= = = = =
Getting java.lang.StackOverflowError when unstashing in Jenkins on Windows 10; happens on one server but not another. Looks like unstash is getting infinite recursion.

• Same name for stash and unstash? -- yes; using same function to unstash on each.
• Reboot Jenkins master and slaves -- yes.
• Enough room on disk to unstash? -- yes.
• Web search on this error -- yes, but this problem not addressed.
• Has this worked in past? -- yes, unstash is working on one server but not another.
• Is target directory clean? -- yes.
• Tried at distinct times? -- yes.

def stash_my_stuff() {
    stash includes: '**', name: 'my_stash'
}
def unstash_my_stuff() {
    unstash 'my_stash'
}

// on one agent
dir("d:\\tmsc") { unstash_my_stuff() }

// later on a different agent
dir("d:\\tmsc") { unstash_my_stuff() }

13:23:33 Running in D:\tmsc
[Pipeline] {
[Pipeline] unstash
[Pipeline] }
[Pipeline] // dir
[Pipeline] dir
13:24:01 Running in D:\tmsc
[Pipeline] {
[Pipeline] End of Pipeline
java.lang.StackOverflowError
    at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:111)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
    at org.jboss.marshalling.river.RiverMarshaller.doSerializableObject(RiverMarshaller.java:988)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:778)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
    at org.jboss.marshalling.river.RiverMarshaller.doSerializableObject(RiverMarshaller.java:988)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
    at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
etc., etc., etc.
sometimes it also includes
    at org.jboss.marshalling.river.RiverMarshaller.doSerializableObject(RiverMarshaller.java:967)

Answer 1

I ran into a similar error and was able to ultimately resolve it by a couple things, one of which MarekR mentioned in his answer.

1. Update the jenkins.xml file to use a 64bit JRE
2. increase max heap size to 1024m for the JRE (in the jenkins.xml file)
3. increase the stack size to 4m in the jenkins.xml as well (-Xss4m)

Finally be sure to save the xml file and restart the jenkins service to pick up the new changes.

Hope this helps!

Answer 2

I've encounter similar problem when using parallel stages.

I've found bug report about that. One of the comment (which is praised by next comment) recommends this:

I encountered this issue too. I am using Jenkins on Windows which was installed using the installer. After some digging, I realized that this distribution of Jenkins comes packaged with a 32-bit version of the JRE, and it is used by the Windows Service (which uses the jenkins.xml file). This severely limits the amount of heap memory the JVM can allocate. If you're facing this issue in the same situation, modify jenkins.xml to use a different, 64-bit version of JRE and also increase the max heap allocation (e.g. -Xmx1024m).

I didn't try that yet (I do not have proper access right to servers with Jenkins), but when I do it I will update the answer.