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:

      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

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Possibly related to JENKINS-38021?

            Show
            jglick Jesse Glick added a comment - Possibly related to JENKINS-38021 ?
            Hide
            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
            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
            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
            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}

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: