Jenkins "java.lang.StackOverflowError" in a CPS pipeline in CI
Pipeline Groovy runs through a CPS (continuation-passing) transform that is far more stack-hungry than plain Groovy. Deep recursion, large loops building call chains, or heavy nested closures can overflow the stack and abort the build with a StackOverflowError.
What this error means
The build fails with java.lang.StackOverflowError and a very long, repeating CPS stack trace (com.cloudbees.groovy.cps...). It often appears with recursive helper functions or large in-pipeline data processing.
java.lang.StackOverflowError
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:90)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg
... (repeats)Common causes
Recursive Groovy under CPS
A recursive function in the pipeline body multiplies stack frames through the CPS transform, overflowing far sooner than plain Groovy would.
Heavy data processing in CPS-transformed code
Large loops or deep closure nesting that build long continuation chains exhaust the thread stack.
How to fix it
Move heavy logic out of CPS
- Mark pure helper methods with
@NonCPSso they run as ordinary Groovy, not CPS. - Replace recursion with iteration, or push the work into a
sh/script step or a compiled shared-library class. - Avoid processing large data structures inside the CPS pipeline body.
@NonCPS
int factorial(int n) { (1..n).inject(1) { a, b -> a * b } }How to prevent it
- Keep the CPS pipeline body thin; delegate computation to
@NonCPSor external scripts. - Prefer iteration over recursion in pipeline Groovy.
- Process large data with
sh/tools, not in-pipeline closures.