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

Unexpected break statement hangs the build

    Details

    • Similar Issues:

      Description

      A pipeline script with an unexpected break statement like this:

      break
      

      .. will hang the build with no feedback.

      The traceback in the server log is:

      WARNING: Unexpected exception in CPS VM thread: CpsFlowExecution[Owner[pipeline-scratch2/29:pipeline-scratch2 #29]]
      java.lang.IllegalStateException: unexpected break statement
              at com.cloudbees.groovy.cps.impl.CallEnv.getBreakAddress(CallEnv.java:62)
              at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:44)
              at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:44)
              at com.cloudbees.groovy.cps.impl.BreakBlock.eval(BreakBlock.java:21)
              at com.cloudbees.groovy.cps.Next.step(Next.java:58)
              at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
              at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
              at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
              at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
              at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
              at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
              at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:163)
              at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:324)
              at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:78)
              at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236)
              at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:224)
              at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63)
              at java.util.concurrent.FutureTask.run(FutureTask.java:266)
              at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
              at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
              at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
              at java.util.concurrent.FutureTask.run(FutureTask.java:266)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
              at java.lang.Thread.run(Thread.java:745)
      

        Attachments

          Activity

          Hide
          eeaston Edward Easton added a comment -

          FWIW this came about due to the changes to the stage() step semantics - I had code nested inside a stage {} block that was itself within a for loop. The break statement was now within a closure and without any context. The worst bit about this is that the thread dump points to the previous line in the code

          Show
          eeaston Edward Easton added a comment - FWIW this came about due to the changes to the stage() step semantics - I had code nested inside a stage {} block that was itself within a for loop. The break statement was now within a closure and without any context. The worst bit about this is that the thread dump points to the previous line in the code
          Hide
          jglick Jesse Glick added a comment -

          Besides fixing the language bug (CallEnv.getBreakAddress should I guess be throwing a CpsCallableInvocation wrapper), the program ought to be treated as finished when some miscellaneous exception is thrown from the CPS VM thread.

          Show
          jglick Jesse Glick added a comment - Besides fixing the language bug ( CallEnv.getBreakAddress should I guess be throwing a CpsCallableInvocation wrapper), the program ought to be treated as finished when some miscellaneous exception is thrown from the CPS VM thread.
          Hide
          abayer Andrew Bayer added a comment -

          Jesse Glick - what should be in that CpsCallableInvocationWrapper?

          Show
          abayer Andrew Bayer added a comment - Jesse Glick - what should be in that CpsCallableInvocationWrapper ?
          Hide
          abayer Andrew Bayer added a comment -

          and fwiw, this doesn't seem to hang the build any more (at least as of workflow-cps 2.45 on my testbed) - the build fails as it would from any other exception, at least with this example:

          stage('foo') {
            echo "hello"
            break
          }
          
          Show
          abayer Andrew Bayer added a comment - and fwiw, this doesn't seem to hang the build any more (at least as of workflow-cps 2.45 on my testbed) - the build fails as it would from any other exception, at least with this example: stage( 'foo' ) { echo "hello" break }

            People

            • Assignee:
              Unassigned
              Reporter:
              eeaston Edward Easton
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: