[JIRA] (JENKINS-56890) IOException: "cannot find current thread"

Visto 2.147 veces
Saltar al primer mensaje no leído

cody.casterline@gmail.com (JIRA)

no leída,
4 abr 2019, 19:08:024/4/19
a jenkinsc...@googlegroups.com
Cody Casterline created an issue
 
Jenkins / Bug JENKINS-56890
IOException: "cannot find current thread"
Issue Type: Bug Bug
Assignee: Unassigned
Components: pipeline
Created: 2019-04-04 23:07
Priority: Minor Minor
Reporter: Cody Casterline

Our server has intermittently been raising an exception which fails builds: 

java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
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

It happens across different projects, and we can't find any commonality between them that might explain how we're ending up in this state. The error is not repeatable – kicking off the build again usually results in a successful build.

Jenkins ver. 2.164.1

(Relevant?) plugin versions:
Pipeline Multibranch: 2.20
Pipeline: Groovy 2.63

I found the line that is throwing the exception in the source code, which seems straightforward, but I don't know why that value is sometimes null.

I'm happy to provide more information to help diagnose this problem if you need something more.

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

cody.casterline@gmail.com (JIRA)

no leída,
8 abr 2019, 11:51:028/4/19
a jenkinsc...@googlegroups.com
Cody Casterline updated an issue
Change By: Cody Casterline
Our server has intermittently been raising an exception which fails builds: 

{{java.io.IOException: cannot find current thread}}
{{at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)}}
{{at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)}}
{{at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)}}
{{at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)}}
{{at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)}}
{{at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)}}
{{at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)}}
{{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}}

It happens across different projects, and we can't find any commonality between them that might explain how we're ending up in this state. The error is not repeatable – kicking off the build again usually results in a successful build.

[Jenkins ver. 2.164.1|https://jenkins.io/]


(Relevant?) plugin versions:
Pipeline Multibranch: 2.20
Pipeline: Groovy 2.63

I found [the line that is throwing the exception in the source code| [ https://github.com/jenkinsci/workflow-cps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsStepContext.java#L300] ] , which seems straightforward, but I don't know why that value is sometimes null.


I'm happy to provide more information to help diagnose this problem if you need something more.

cody.casterline@gmail.com (JIRA)

no leída,
8 abr 2019, 19:41:048/4/19
a jenkinsc...@googlegroups.com
Cody Casterline commented on Bug JENKINS-56890
 
Re: IOException: "cannot find current thread"

We enabled logging for the CpsStepContext class and got some interesting results:

Apr 08, 2019 12:02:00 PM FINE org.jenkinsci.plugins.workflow.cps.CpsStepContext

no thread 356 among [0, 2, 4, 8, 352, 354, 356]
java.lang.IllegalStateException
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThread(CpsStepContext.java:226)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:237)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:298)
	at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
	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)

Apr 08, 2019 3:36:03 PM FINE org.jenkinsci.plugins.workflow.cps.CpsStepContext

no thread 296 among [0, 2, 4, 8, 18, 34, 37, 41, 44, 48, 296]
java.lang.IllegalStateException
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThread(CpsStepContext.java:226)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:237)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:298)
	at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.makeLauncher(DefaultStepContext.java:147)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:75)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
	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)

In both cases, the thread IDs being looked up do exist in the `threads` TreeSet, but their value is null? But I don't see anywhere where a null value gets inserted into that TreeSet. Could this be a race condition, accessing that value as it's being added/removed by another thread?

maddimax@gmail.com (JIRA)

no leída,
11 abr 2019, 8:46:0211/4/19
a jenkinsc...@googlegroups.com

We are running into the same issues since updating to Jenkins ver. 2.164.2 and updating all plugins.

block.jon@gmail.com (JIRA)

no leída,
11 abr 2019, 10:27:0311/4/19
a jenkinsc...@googlegroups.com
Jon B commented on Bug JENKINS-56890

I just had a build fail with this problem

java.io.IOException: cannot find current thread
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
	at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
	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 

wdforson@gmail.com (JIRA)

no leída,
11 abr 2019, 12:16:0311/4/19
a jenkinsc...@googlegroups.com

looking at the class methods where "threads" (a TreeMap) is accessed: https://github.com/jenkinsci/workflow-cps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsThreadGroup.java#L176-L195

I see that there is an attempt to ensure that all "put" calls are executed within the same thread – but AFAICT there is no such logic for "get".

Given that TreeMap is NOT a thread-safe class, if calls to "threads.put" and "threads.get" are interleaved, it is entirely possible to get "null" when invoking "get" for a key that has been "put" in another thread.

Even without interleaved execution, I believe it would be possible to get such behavior simply via invoking "put" and "get" in different threads without any synchronization constructs, in terms of the Java Memory Model (but my own memory regarding the JMM is pretty hazy).

In other words, from a glance, it really just looks like "threads" is being manipulated in a non-threadsafe manner.

mstewart@riotgames.com (JIRA)

no leída,
12 abr 2019, 15:53:0112/4/19
a jenkinsc...@googlegroups.com

Can confirm this issue happens in Jenkins 2.168 as well (Centos). We've been running into this daily (several thousand jobs a day, see this at least once or twice a day)

liejuntao001@gmail.com (JIRA)

no leída,
15 abr 2019, 16:47:0315/4/19
a jenkinsc...@googlegroups.com

I got this very similar error on Jenkins 2.150.3

It happened at the end of the pipeline.


java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)

at org.jenkinsci.plugins.workflow.support.DefaultStepContext.getListener(DefaultStepContext.java:114)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:79)


at org.jenkinsci.plugins.workflow.support.DefaultStepContext.makeLauncher(DefaultStepContext.java:147)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:75)

at org.jenkinsci.plugins.workflow.steps.CoreWrapperStep$Callback.finished(CoreWrapperStep.java:152)
at org.jenkinsci.plugins.workflow.steps.CoreWrapperStep$Execution2$Callback2.finished(CoreWrapperStep.java:122)


at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
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
 

leonardo.pruna@das.es (JIRA)

no leída,
17 abr 2019, 9:32:0217/4/19
a jenkinsc...@googlegroups.com

Same issue here:

java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)

at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)

at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
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)

 

Jenkins: 2.164.1

Groovy: 2.65

 

konpro11@o2.pl (JIRA)

no leída,
23 abr 2019, 10:25:0223/4/19
a jenkinsc...@googlegroups.com

Jenkins 2.164.1:

 
15:55:20 ERROR during Build: java.io.IOException: cannot find current thread*15:55:20* at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)15:55:20 at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)15:55:20 at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)15:55:20 at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)15:55:20 at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)15:55:20 at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)15:55:20 at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)

wdforson@gmail.com (JIRA)

no leída,
23 abr 2019, 10:34:0123/4/19
a jenkinsc...@googlegroups.com
William F edited a comment on Bug JENKINS-56890
looking at the class methods where "threads" (a TreeMap) is accessed: https://github.com/jenkinsci/workflow-cps-plugin/blob/ master f610f0bcf732b13ff542dd4f716d9520988f99a7 /src/main/java/org/jenkinsci/plugins/workflow/cps/CpsThreadGroup.java# L176 L186 - L195 L205

I see that there is an attempt to ensure that all "put" calls are executed within the same thread -- but AFAICT there is no such logic for "get".


Given that TreeMap is NOT a thread-safe class, if calls to "threads.put" and "threads.get" are interleaved, it is entirely possible to get "null" when invoking "get" for a key that has been "put" in another thread.

Even without interleaved execution, I believe it would be possible to get such behavior simply via invoking "put" and "get" in different threads without any synchronization constructs, in terms of the Java Memory Model (but my own memory regarding the JMM is pretty hazy).

In other words, from a glance, it really just looks like "threads" is being manipulated in a non-threadsafe manner.

nullify005@gmail.com (JIRA)

no leída,
1 may 2019, 18:37:041/5/19
a jenkinsc...@googlegroups.com
Lee Webb updated an issue
 
Change By: Lee Webb
Priority: Minor Critical

nullify005@gmail.com (JIRA)

no leída,
1 may 2019, 18:39:021/5/19
a jenkinsc...@googlegroups.com
Lee Webb commented on Bug JENKINS-56890
 
Re: IOException: "cannot find current thread"

I feel compelled to raise this to major because it's basically causing 25% of our builds to randomly fail & there really isn't a workaround for it.

wdforson@gmail.com (JIRA)

no leída,
2 may 2019, 10:56:102/5/19
a jenkinsc...@googlegroups.com

Again, based on a perfunctory glance at the proximal code (and, admittedly, with absolutely no understanding of the codebase as a whole), I suspect this issue could be fixed by simply synchronizing all access to the underlying "threads" TreeMap.

One potential approach would be to follow the advice given in the TreeMap documentation:

Note that this implementation is not synchronized. If multiple threads access a map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with an existing key is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedSortedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:

SortedMap m = Collections.synchronizedSortedMap(new TreeMap(...));

I get the impression that the authors of the code hoped to avoid the need for explicit synchronization by forcing all write operations to execute in a single thread...but, as noted in the javadoc excerpt above, that's not good enough.

nullify005@gmail.com (JIRA)

no leída,
8 may 2019, 22:06:028/5/19
a jenkinsc...@googlegroups.com
Lee Webb commented on Bug JENKINS-56890

I have been able to work around this by going back to a copy of the plugins & Jenkins version I had at the beginning of March before the problem started for me in April.

The versions without this issue appear to be (at least in my case):

  • Jenkins 2.161
  • Pipeline: Basic Steps 2.14
  • Pipeline: Build Step 2.7
  • Pipeline: Groovy 2.63
  • Pipeline: Nodes and Processes 2.29

Yes, there are sec vulnerabilities raised for both the Jenkins version & the plugins, but having random build failures which aren't project related undermines CI/CD ...

I was running Jenkins 2.164 & attempting to use Pipeline: Groovy 2.62 -> 2.67 and all of them appeared to have the same issue, so the 'problem' itself might not be within the workflow cps plugin & it might be in another supporting Pipeline plugin or Jenkins itself, but I can't test all the combinations to find out.

dnusbaum@cloudbees.com (JIRA)

no leída,
9 may 2019, 9:38:099/5/19
a jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

no leída,
9 may 2019, 9:38:099/5/19
a jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
Change By: Devin Nusbaum
Component/s: workflow-cps-plugin
Component/s: pipeline

wdforson@gmail.com (JIRA)

no leída,
9 may 2019, 9:51:049/5/19
a jenkinsc...@googlegroups.com
William F commented on Bug JENKINS-56890
 
Re: IOException: "cannot find current thread"

I just created this PR: https://github.com/jenkinsci/workflow-cps-plugin/pull/287.

As noted in the PR summary, I haven't done any testing to confirm that this fixes the issue – or, for that matter, to definitively identify the root cause. But that change does partially address some glaring thread-safety issues, so hopefully it will get picked up.

 

(and as to Lee Webb's experiences with different version combinations: as you say, perhaps the root cause lies in another component altogether, but OTOH, if the issue is indeed non-threadsafe manipulation of a collection, such bugs can often manifest in ways that are surprisingly subtle – and, in some cases, the particular manifestation can be affected by apparently unrelated changes)

dnusbaum@cloudbees.com (JIRA)

no leída,
9 may 2019, 10:07:089/5/19
a jenkinsc...@googlegroups.com

Thanks everyone for the detailed investigation! From what I can tell it looks like the root cause is that steps using the new GeneralNonBlockingStepExecution API (JENKINS-49337) introduced in Pipeline: Step API 2.18 that interact with StepContext inside of their completion callback will do so not on the CPS VM thread, leading to the unsafe access of the TreeMap and the reported issue.

I'll take a look at the submitted PR. It looks ok to me at a glance, although I wonder if there could be other problems with running the completion callback in {{GeneralNonBlockingStepExecution }} on a separate thread (maybe we need to fix that instead of just making the collection thread safe), and I'm not sure if it fixes the reported issue. If anyone seeing the issue has a Jenkins instance on which you are comfortable testing pre-release plugins and are able to consistently reproduce the issue, feel free to install the .hpi file here which is a build of the plugin that includes that that PR and let us know whether it seems to help or not.

dnusbaum@cloudbees.com (JIRA)

no leída,
9 may 2019, 17:27:029/5/19
a jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-56890
Thanks everyone for the detailed investigation! From what I can tell it looks like the root cause is that steps using the new {{GeneralNonBlockingStepExecution}} API (JENKINS-49337) introduced in Pipeline: Step API 2.18 that interact with {{StepContext}} inside of their completion callback will do so not on the CPS VM thread, leading to the unsafe access of the {{TreeMap}} and the reported issue.

I'll take a look at the [submitted PR|https://github.com/jenkinsci/workflow-cps-plugin/pull/287]. It looks ok to me at a glance, although I wonder if there could be other problems with running the completion callback in {{GeneralNonBlockingStepExecution }} on a separate thread (maybe we need to fix that instead of just making the collection thread safe), and I'm not sure if it fixes the reported issue. If anyone seeing the issue has a Jenkins instance on which you are comfortable testing pre-release plugins and are able to consistently reproduce the issue, feel free to install the .hpi file [here|https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/workflow/workflow-cps/2.68-rc2272.ba3575b51e37/] which is a build of the plugin that includes that that PR and let us know whether it seems to help or not.

If anyone has a standalone (ideally minimal) Pipeline that reproduces the issue somewhat consistently I would be interested to see it so that we can test the proposed fix. I tried to reproduce the problem in a test but was only able to reproduce JENKINS-50474.

dnusbaum@cloudbees.com (JIRA)

no leída,
10 may 2019, 15:58:0810/5/19
a jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

no leída,
10 may 2019, 15:58:0910/5/19
a jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

no leída,
10 may 2019, 15:58:0910/5/19
a jenkinsc...@googlegroups.com
Devin Nusbaum started work on Bug JENKINS-56890
 
Change By: Devin Nusbaum
Status: Open In Progress

edburns@java.net (JIRA)

no leída,
13 may 2019, 12:58:0313/5/19
a jenkinsc...@googlegroups.com

java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
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)

edburns@java.net (JIRA)

no leída,
13 may 2019, 13:03:0613/5/19
a jenkinsc...@googlegroups.com
edburns edited a comment on Bug JENKINS-56890
Jenkins version:
h1. 2.164.2

 

I am seeing this also:
{quote}java.io.IOException: cannot find current thread

at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
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)
{quote}

edburns@java.net (JIRA)

no leída,
13 may 2019, 13:06:0313/5/19
a jenkinsc...@googlegroups.com
edburns edited a comment on Bug JENKINS-56890
Jenkins version :
h1.
2.164.2
Pipeline: Basic Steps 2.15
  Pipeline: Build Step 2.9
Pipeline: Groovy 2.67
Pipeline: Nodes and Processes 2.30

jglick@cloudbees.com (JIRA)

no leída,
24 may 2019, 10:19:0324/5/19
a jenkinsc...@googlegroups.com

I wonder if there could be other problems with running the completion callback in GeneralNonBlockingStepExecution on a separate thread (maybe we need to fix that instead of just making the collection thread safe)

Long before this API was introduced, steps were sometimes calling StepContext.get from arbitrary threads, whether that happened to be part of callback processing or not. (simple example) It is expected to be thread-safe.

dnusbaum@cloudbees.com (JIRA)

no leída,
28 may 2019, 16:51:5828/5/19
a jenkinsc...@googlegroups.com
 

A potential fix for this issue was just released in version 2.69 of Pipeline Groovy Plugin. I was never able to reproduce the issue in a test, so there is a possibility that it is still not fixed, so if you still see the issue in version 2.69 please reopen the ticket and include the stack trace you are getting.

Change By: Devin Nusbaum
Status: In Review Resolved
Resolution: Fixed
Released As: workflow-cps 2.69

dnusbaum@cloudbees.com (JIRA)

no leída,
28 may 2019, 16:52:0228/5/19
a jenkinsc...@googlegroups.com

janczuk.mateusz@gmail.com (JIRA)

no leída,
31 may 2019, 3:38:0231/5/19
a jenkinsc...@googlegroups.com
Mateusz Janczuk commented on Bug JENKINS-56890
 
Re: IOException: "cannot find current thread"

Devin Nusbaum thanks for the fix  I did update 2 days ago to Pipeline Groovy Plugin 2.69, and it looks that exception disappeared. Before upgrade I saw exception at least 2 times a day, after updating, not once (Jenkins LTS 2.164.3).

craig@2ndquadrant.com (JIRA)

no leída,
3 jun 2019, 21:55:033/6/19
a jenkinsc...@googlegroups.com

FWIW, I found a possibly-related crash that turned out to be in my own code. I was using a groovy `Map` that was modified by multiple closures run within a `parallel` step. This caused similar exceptions as well as odd incorrect map entries etc.

So keep an eye out for that. Posting here for people who see this later.

jglick@cloudbees.com (JIRA)

no leída,
4 jun 2019, 15:39:024/6/19
a jenkinsc...@googlegroups.com

Craig Ringer that ought to be safe, since the CPS VM runs green threads, and in no event should it cause an error like the one reported here which is below userspace. If you can reproduce such a problem, please file it separately.

Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos