-
Bug
-
Resolution: Fixed
-
Critical
-
Current workflow-plugin docker image
The following script for some reason will make Jenkins go out of memory and will never complete the execution.
node {
HipNotifier chip = new HipNotifier('A')
echo chip.name
}
public class HipNotifier {
private String name;
public HipNotifier(String pName) {
this.name = pName
}
String getName() {
return name
}
}
- depends on
-
JENKINS-25550 Hard kill
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
JENKINS-32986 hard killing a pipeline leaves the JVM CPS thread running.
-
- Open
-
- relates to
-
-
- Open
-
-
-
- Open
-
- links to
[JENKINS-31484] Endless loop in DefaultInvoker.getProperty when accessing field via getter/setter without @
A hard kill from JENKINS-25550 allows the build to be marked as aborted, but does not actually kill the CpsVmExecutorService call, so Jenkins will still crash. Probably need to escalate to a Thread.stop in such a case.
Similar issue occured when using getter in class of pipeline global shared lib. We decided not use getters for now. Any solutions for this problem?
As a workaround, try explicitly calling .getName() rather than using the .name shorthand. Have not yet found time to track down the actual issue; probably some mistake in groovy-cps.
Reproduced hang in test, but cannot find anything in the physical thread dump; high CPU activity seems to be in GC threads. I do see:
com.cloudbees.jenkins.support.SupportPlugin writeBundle WARNING: Could not attach 'nodes/master/pipeline-thread-dump.txt' to support bundle java.lang.StackOverflowError at com.cloudbees.groovy.cps.impl.SourceLocation.toStackTrace(SourceLocation.java:22) at com.cloudbees.groovy.cps.impl.CallEnv.buildStackTraceElements(CallEnv.java:101) at com.cloudbees.groovy.cps.impl.FunctionCallEnv.buildStackTraceElements(FunctionCallEnv.java:13) at com.cloudbees.groovy.cps.impl.ProxyEnv.buildStackTraceElements(ProxyEnv.java:64) at com.cloudbees.groovy.cps.impl.ProxyEnv.buildStackTraceElements(ProxyEnv.java:64) at com.cloudbees.groovy.cps.impl.CallEnv.buildStackTraceElements(CallEnv.java:103) at com.cloudbees.groovy.cps.impl.FunctionCallEnv.buildStackTraceElements(FunctionCallEnv.java:13) at …
Using .getName() rather than .name is not the issue, since the bug is inside the getter itself. The workaround is to use the more explicit:
String getName() {this.@name}
Similarly for setters:
void setName(String name) {this.@name = name}
It is worth noting that this behavior of accessing the backing field directly is done in order to prevent a stack overflow when using the property access syntax within a class that defines the property.
Intuitive enough, though it is hard to see how a CompilationCustomizer is supposed to be informed of this difference. In the proposed PR I just used trial and error. Javadoc is minimal to nonexistent, as is typical in Groovy sources.
Ran into another variant of this issue, and opened a PR against groovy-cps with an ignored test case: https://github.com/cloudbees/groovy-cps/pull/95. The issue is that a getter like the following works in regular Groovy, but fails with a StackOverflowError in groovy-cps:
String getName() {this.name}
Megan Smith
added a comment - This still seems broken - we just ran into it with Jenkins version Jenkins 2.235.2
Megan Smith
added a comment - This still seems broken - we just ran into it with Jenkins version Jenkins 2.235.2
Reproducible: