[JIRA] (JENKINS-57253) Illegal 'break' statement in Jenkinsfile freeze Jenkins resources

31 views
Skip to first unread message

cheney.yan@gmail.com (JIRA)

unread,
Apr 30, 2019, 9:07:02 AM4/30/19
to jenkinsc...@googlegroups.com
Cheney Yan created an issue
 
Jenkins / Improvement JENKINS-57253
Illegal 'break' statement in Jenkinsfile freeze Jenkins resources
Issue Type: Improvement Improvement
Assignee: Unassigned
Components: _unsorted
Created: 2019-04-30 13:06
Environment: Jenkins 2.150.2
Groovy 2.0/2.2
Pipeline 2.5/2.6
Priority: Blocker Blocker
Reporter: Cheney Yan

When there is an illegal 'break' statement exists, the job fails and finish. However, from Main page, job are not reported as failed/finished but hangs. It consumes the execution slot of the slave and never quit. 

A quick script to reproduce this:

```

node('linux')

{  break; }

```

 

The output of the execution:

```
‘...’ is offline
Running on ... in /home/ubuntu/workspace/s_devops-deploy-tool-test_master[Pipeline] {[Pipeline] End of PipelineGitHub has been notified of this commit’s build result

java.lang.IllegalStateException: unexpected break statement
at com.cloudbees.groovy.cps.impl.CallEnv.getBreakAddress(CallEnv.java:102)
at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
at com.cloudbees.groovy.cps.impl.BreakBlock.eval(BreakBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:347)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:259)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:247)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
 
When I change the statement `break` to others like `return`, `throw Exception...` or even illegal keywords, things runs as expected. 
Have tried different combinations of plug-ins but it does not seem related. 

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

o.v.nenashev@gmail.com (JIRA)

unread,
May 3, 2019, 8:03:02 AM5/3/19
to jenkinsc...@googlegroups.com
Oleg Nenashev updated an issue
Change By: Oleg Nenashev
Component/s: pipeline
Component/s: _unsorted

me@basilcrow.com (JIRA)

unread,
May 7, 2020, 2:08:03 AM5/7/20
to jenkinsc...@googlegroups.com
Basil Crow commented on Improvement JENKINS-57253
 
Re: Illegal 'break' statement in Jenkinsfile freeze Jenkins resources

I hit this issue today. As described in the initial report, this leaked an executor on my SSH build agent. The stack trace was as follows:

[Pipeline] End of Pipeline
java.lang.IllegalStateException: unexpected break statement
	at com.cloudbees.groovy.cps.impl.CallEnv.getBreakAddress(CallEnv.java:102)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.LoopBlockScopeEnv.getBreakAddress(LoopBlockScopeEnv.java:29)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.ProxyEnv.getBreakAddress(ProxyEnv.java:52)
	at com.cloudbees.groovy.cps.impl.BreakBlock.eval(BreakBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:185)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:400)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$400(CpsThreadGroup.java:96)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:312)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:276)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	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:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

me@basilcrow.com (JIRA)

unread,
May 7, 2020, 2:10:03 AM5/7/20
to jenkinsc...@googlegroups.com
Basil Crow updated an issue
 
Change By: Basil Crow
Component/s: workflow-cps-plugin

me@basilcrow.com (JIRA)

unread,
May 7, 2020, 2:57:03 AM5/7/20
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
May 7, 2020, 10:14:02 AM5/7/20
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
May 7, 2020, 10:14:03 AM5/7/20
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
May 7, 2020, 11:29:02 AM5/7/20
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
May 7, 2020, 11:29:03 AM5/7/20
to jenkinsc...@googlegroups.com
Devin Nusbaum started work on Improvement JENKINS-57253
 
Change By: Devin Nusbaum
Status: Open In Progress

dnusbaum@cloudbees.com (JIRA)

unread,
May 7, 2020, 11:29:03 AM5/7/20
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
May 7, 2020, 11:30:02 AM5/7/20
to jenkinsc...@googlegroups.com
Devin Nusbaum commented on Improvement JENKINS-57253
 
Re: Illegal 'break' statement in Jenkinsfile freeze Jenkins resources

I filed https://github.com/cloudbees/groovy-cps/pull/109 to turn these into compilation failures instead of runtime failures, which matches the behavior of regular Groovy and avoids issues related to not cleaning up resources correctly.

Reply all
Reply to author
Forward
0 new messages