Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-31484

Endless loop in DefaultInvoker.getProperty when accessing field via getter/setter without @

    XMLWordPrintable

    Details

    • Similar Issues:
    • Epic Link:

      Description

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

        Attachments

          Issue Links

          depends on

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-25550 Hard kill

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-38021 Accessing unset global variable cause master to hang

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-41412 Pipeline library with method name matching synthetic accessor crashes Jenkins

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-42170 Referencing a vars implicit property that is not set causes build to hang forever

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved
          is related to

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-32986 hard killing a pipeline leaves the JVM CPS thread running.

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          relates to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-41984 StackOverflowError : Unexpected exception in CPS VM thread: CpsFlowExecution

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-45834 Setters for shared pipeline scripts not getting called

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          links to

          Web Link cloudbees/groovy-cps#95

          Web Link Groovy docs: Properties

          Web Link groovy-cps PR 45

            Activity

            Ascending order - Click to sort in descending order
            7 older comments
            Hide
            Permalink
            jglick Jesse Glick added a comment -

            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 …
            Show
            jglick Jesse Glick added a comment - 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 …
            Hide
            Permalink
            jglick Jesse Glick added a comment -

            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}
            Show
            jglick Jesse Glick added a comment - 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}
            Hide
            Permalink
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            Permalink
            dnusbaum Devin Nusbaum added a comment -

            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}
            Show
            dnusbaum Devin Nusbaum added a comment - 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}
            Hide
            Permalink
            megaloni Megan Smith added a comment -

            This still seems broken - we just ran into it with Jenkins version Jenkins 2.235.2

            Show
            megaloni Megan Smith added a comment - This still seems broken - we just ran into it with Jenkins version Jenkins 2.235.2

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              vexdev Luca Vitucci
              Votes:
              4 Vote for this issue
              Watchers:
              13 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: