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

IllegalArgumentException: array element type mismatch from GroovyCallSiteSelector.parametersForVarargs calling String.join with a List

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • script-security-plugin
    • None
    • Script Security 1.21, Jenkins 2.18
    • Pipeline - December

      Pipeline fails if I pass an iterable parameter to String.join, with an error message suggesting it tried to use the vararg overload.

      Jenkinsfile:

      def lst = ['a', 'bc', 'def']
echo "Lst: $lst"

// Works
def str = String.join('\n', lst.toArray(new String[lst.size()]))
echo "Str: $str"

// Doesn't work
def str2 = String.join('\n', lst)
echo "Str2: ${str2}"

      Console text:

      Started by user dsobral
DatadogBuildListener.java: Started build!
DatadogBuildListener.java: Using unix hostname found via `/bin/hostname -f`. Hostname: sfdev-061.richrelevance.com
DatadogBuildListener.java: Sending event
DatadogBuildListener.java: API call of type 'v1/events' was sent successfully!
DatadogBuildListener.java: Payload: {"alert_type":"info","title":"string_join_test build #5 started on sfdev-061.richrelevance.com","text":"%%% \n [Follow build #5 progress](https://jenkins.richrelevance.com/job/string_join_test/5/)  \n %%%","date_happened":1471555196,"event_type":"build start","host":"sfdev-061.richrelevance.com","tags":["job:string_join_test"],"aggregation_key":"string_join_test"}
[Pipeline] echo
Lst: [a, bc, def]
[Pipeline] echo
Str: a
bc
def
[Pipeline] End of Pipeline
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
DatadogBuildListener.java: Completed build!
DatadogBuildListener.java: Using unix hostname found via `/bin/hostname -f`. Hostname: sfdev-061.richrelevance.com
DatadogBuildListener.java: Sending event
DatadogBuildListener.java: API call of type 'v1/events' was sent successfully!
DatadogBuildListener.java: Payload: {"source_type_name":"jenkins","alert_type":"failure","title":"string_join_test build #5 failed on sfdev-061.richrelevance.com","text":"%%% \n [See results for build #5](https://jenkins.richrelevance.com/job/string_join_test/5/) (0.0 secs) \n %%%","date_happened":1471555196,"event_type":"build result","host":"sfdev-061.richrelevance.com","result":"FAILURE","tags":["job:string_join_test","result:FAILURE"],"aggregation_key":"string_join_test"}
DatadogBuildListener.java: Sending metric 'jenkins.job.duration' with value 0.0
DatadogBuildListener.java: API call of type 'v1/series' was sent successfully!
DatadogBuildListener.java: Payload: {"series":[{"metric":"jenkins.job.duration","points":[[1471555199,0]],"type":"gauge","host":"sfdev-061.richrelevance.com","tags":["job:string_join_test","result:FAILURE"]}]}
DatadogBuildListener.java: Sending service check 'jenkins.job.status' with status 2
DatadogBuildListener.java: API call of type 'v1/check_run' was sent successfully!
DatadogBuildListener.java: Payload: {"check":"jenkins.job.status","host_name":"sfdev-061.richrelevance.com","timestamp":1471555199,"status":2,"tags":["job:string_join_test","result:FAILURE"]}
java.lang.IllegalArgumentException: array element type mismatch
	at java.lang.reflect.Array.set(Native Method)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovyCallSiteSelector.parametersForVarargs(GroovyCallSiteSelector.java:102)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovyCallSiteSelector.matches(GroovyCallSiteSelector.java:49)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovyCallSiteSelector.findMatchingMethod(GroovyCallSiteSelector.java:177)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovyCallSiteSelector.staticMethod(GroovyCallSiteSelector.java:171)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onStaticCall(SandboxInterceptor.java:135)
	at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:180)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.java:177)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:91)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
	at WorkflowScript.run(WorkflowScript:9)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:48)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
	at sun.reflect.GeneratedMethodAccessor852.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.LocalVariableBlock$LocalVariable.get(LocalVariableBlock.java:33)
	at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
	at com.cloudbees.groovy.cps.impl.LocalVariableBlock.evalLValue(LocalVariableBlock.java:22)
	at com.cloudbees.groovy.cps.LValueBlock$BlockImpl.eval(LValueBlock.java:55)
	at com.cloudbees.groovy.cps.LValueBlock.eval(LValueBlock.java:16)
	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:164)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:360)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:226)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
	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)
Finished: FAILURE

          [JENKINS-37527] IllegalArgumentException: array element type mismatch from GroovyCallSiteSelector.parametersForVarargs calling String.join with a List

          Alex Varju added a comment -

          Seeing the same thing here when calling a constructor that has overloads where one variant uses varargs:

          String paramName = "whatever"
List<ParameterValue> parameters = [ new BooleanParameterValue( paramName, true ) ]
Collection<String> additionalSafeParameters = [ paramName ]
new ParametersAction( parameters, additionalSafeParameters )

          Alex Varju added a comment - Seeing the same thing here when calling a constructor that has overloads where one variant uses varargs: String paramName = "whatever" List<ParameterValue> parameters = [ new BooleanParameterValue( paramName, true ) ] Collection< String > additionalSafeParameters = [ paramName ] new ParametersAction( parameters, additionalSafeParameters )

          Lucky Luke added a comment -

          hi

          does someone have a workaround for the bug shown by Alex Varju?

          Thanks for your help

          M

          Lucky Luke added a comment - hi does someone have a workaround for the bug shown by Alex Varju? Thanks for your help M

          Jarrod Cabalzar added a comment - - edited

          I also hit the same issue as described by Alex above whilst trying to work around the MultiJob - Pipeline subjob issues seen here: JENKINS-38825

          Jarrod Cabalzar added a comment - - edited I also hit the same issue as described by Alex above whilst trying to work around the MultiJob - Pipeline subjob issues seen here: JENKINS-38825

          Peter Wiseman added a comment - - edited

          I'd like to request this be upgraded from Minor to Major.

          In addition to preventing use of ParametersAction with additionalSafe parameters (Alex's case above), it's preventing use of scheduleBuild2 with both a Cause and Action (referenced in JENKINS-46189).  I don't think there are any available workarounds.

          Peter Wiseman added a comment - - edited I'd like to request this be upgraded from Minor to Major. In addition to preventing use of ParametersAction with additionalSafe parameters (Alex's case above), it's preventing use of scheduleBuild2 with both a Cause and Action (referenced in JENKINS-46189 ).  I don't think there are any available workarounds.

          Jesse Glick added a comment -

          Workaround is probably to pass an explicit array argument rather than using varargs. TBD.

          Priority in JIRA is meaningless. Either a developer has time to work on a fix, or they do not. If you like you may vote for an issue. Adding comments without new information is just an annoyance.

          Jesse Glick added a comment - Workaround is probably to pass an explicit array argument rather than using varargs. TBD. Priority in JIRA is meaningless. Either a developer has time to work on a fix, or they do not. If you like you may vote for an issue. Adding comments without new information is just an annoyance.

          Peter Wiseman added a comment -

          Thanks Jesse.  Understood re priority.  The new information was an additional impact with lack of a workaround.  i.e. scheduleBuild2 can't be called with Cause and Action.  I don't think a workaround is possible in either of these two cases as the varargs takes priority, and doesn't accept the parameters needed (for ParametersAction with additionalSafe paraeters, and for scheduleBuild2 with a cause).  Granted that doesn't help identify the root cause of the problem.  I have included my vote.

          Peter Wiseman added a comment - Thanks Jesse.  Understood re priority.  The new information was an additional impact with lack of a workaround.  i.e. scheduleBuild2 can't be called with Cause and Action.  I don't think a workaround is possible in either of these two cases as the varargs takes priority, and doesn't accept the parameters needed (for ParametersAction with additionalSafe paraeters, and for scheduleBuild2 with a cause).  Granted that doesn't help identify the root cause of the problem.  I have included my vote.

          Jesse Glick added a comment -

          Overload disambiguation in Groovy is indeed hard. Anyway you should avoid calling internal Jenkins APIs like scheduleBuild2. From Pipeline, use the build step.

          Jesse Glick added a comment - Overload disambiguation in Groovy is indeed hard. Anyway you should avoid calling internal Jenkins APIs like scheduleBuild2 . From Pipeline, use the build step.

          Peter Wiseman added a comment -

          Thanks Jesse. To help understanding the impact for us... Avoiding scheduleBuild2 is easy to say, harder to do.  Switching to Pipeline is easy to say, harder to do.  It's only relatively recently (just before Pipeline came out in Jenkins 2.0) that we moved to using groovy scripts to schedule jobs, and we've experienced a high value add by using scheduleBuild2 (i.e. Futures) to enable logging and linkage between the parent and child jobs.  Whilst we do need to invest in a switch to Pipeline, it's too soon for us, given the investment we have already made in the current scripting.  In the mean-time, the combination of recent Sandbox/Security enforcements prevent scheduleBuild2 being used in file based groovy scripts, and there is no option to avoid the sandbox, hence it blocks an upgrade.

          Peter Wiseman added a comment - Thanks Jesse. To help understanding the impact for us... Avoiding scheduleBuild2 is easy to say, harder to do.  Switching to Pipeline is easy to say, harder to do.  It's only relatively recently (just before Pipeline came out in Jenkins 2.0) that we moved to using groovy scripts to schedule jobs, and we've experienced a high value add by using scheduleBuild2 (i.e. Futures) to enable logging and linkage between the parent and child jobs.  Whilst we do need to invest in a switch to Pipeline, it's too soon for us, given the investment we have already made in the current scripting.  In the mean-time, the combination of recent Sandbox/Security enforcements prevent scheduleBuild2 being used in file based groovy scripts, and there is no option to avoid the sandbox, hence it blocks an upgrade.

          Jesse Glick added a comment -

          Sorry, original comment referred to Pipeline so it was unclear. There is very likely a workaround involving using a slightly different API, such as ParameterizedJobMixIn.scheduleBuild2(Job, int, Action...).

          Jesse Glick added a comment - Sorry, original comment referred to Pipeline so it was unclear. There is very likely a workaround involving using a slightly different API, such as ParameterizedJobMixIn.scheduleBuild2(Job, int, Action...) .

          Andrew Bayer added a comment -

          The fix for JENKINS-47159 also fixes this, so I've added a test verifying that to https://github.com/jenkinsci/script-security-plugin/pull/156.

          Andrew Bayer added a comment - The fix for JENKINS-47159 also fixes this, so I've added a test verifying that to https://github.com/jenkinsci/script-security-plugin/pull/156 .

            abayer Andrew Bayer
            dcsobral Daniel Sobral
            Votes:
            10 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: