Skip to content
Latchkey

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.

Jenkins console
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

  1. Mark pure helper methods with @NonCPS so they run as ordinary Groovy, not CPS.
  2. Replace recursion with iteration, or push the work into a sh/script step or a compiled shared-library class.
  3. Avoid processing large data structures inside the CPS pipeline body.
Jenkinsfile
@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 @NonCPS or external scripts.
  • Prefer iteration over recursion in pipeline Groovy.
  • Process large data with sh/tools, not in-pipeline closures.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →