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

java.lang.ArrayIndexOutOfBoundsException: 1- Source checkout issue

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • git-client-plugin
    • Windows 8.1, Windows server 2012, Windows 10 64-bit,
      JDK 1.8.131, Jenkins 2.77
      git-client plugin:2.3.0

      We are getting "java.lang.ArrayIndexOutOfBoundsException: 1" exception in pipeline project during source checkout time. This issue occurs most of the time. Due to this, our Continuous Integration process is affected very much. Can you please check and provide the solution to this?

      Note: Jenkins installed on a Linux machine(Master) as a dbm package and i have connected slave machines as Windows machines. I have also set the timeout to 50 in both advanced checkout and clone behaviors. 

      Below is my sample code
      node {
      stage 'Checkout'{

      {
      checkout scm 

      }

      }

       

      Error Details:

      Running on 24.9.6.17 in C:\workspace\DataFolder\Server
      [Pipeline] {
      [Pipeline] timestamps
      [Pipeline] {
      [Pipeline] timeout
      16:07:57 Timeout set to expire in 2 hr 0 min
      [Pipeline] {
      [Pipeline] stage (Checkout)
      16:07:57 Using the ‘stage’ step without a block argument is deprecated
      16:07:57 Entering stage Checkout
      16:07:57 Proceeding
      [Pipeline] dir
      16:07:57 Running in C:\workspace\DataFolder\Server\server
      [Pipeline] {
      [Pipeline] checkout
      16:07:58 > C:\Program Files\Git\bin\git.exe rev-parse --is-inside-work-tree # timeout=10
      16:07:58 Fetching changes from the remote Git repository
      16:07:58 > C:\Program Files\Git\bin\git.exe config remote.origin.url https://gitlab.test.com/data-folder/server # timeout=10
      16:07:58 Cleaning workspace
      16:07:58 > C:\Program Files\Git\bin\git.exe rev-parse --verify HEAD # timeout=10
      16:07:59 Resetting working tree
      16:07:59 > C:\Program Files\Git\bin\git.exe reset --hard # timeout=10
      16:07:59 > C:\Program Files\Git\bin\git.exe clean -fdx # timeout=10
      16:07:59 Fetching upstream changes from https://gitlab.test.com/data-folder/server
      16:07:59 > C:\Program Files\Git\bin\git.exe --version # timeout=10
      16:08:00 using GIT_ASKPASS to set credentials
      16:08:00 > C:\Program Files\Git\bin\git.exe fetch --tags --progress https://gitlab.test.com/data-folder/server +refs/heads/:refs/remotes/origin/ +refs/merge-requests//head:refs/remotes/origin/merge-requests/ # timeout=50
      16:08:05 > C:\Program Files\Git\bin\git.exe rev-parse "5c2e31279bef38916492d077fa8e55162e41e1cb^{commit}" # timeout=10
      16:08:05 Checking out Revision 5c2e31279bef38916492d077fa8e55162e41e1cb (detached)
      16:08:05 > C:\Program Files\Git\bin\git.exe config core.sparsecheckout # timeout=10
      16:08:05 > C:\Program Files\Git\bin\git.exe checkout -f 5c2e31279bef38916492d077fa8e55162e41e1cb # timeout=50
      16:08:05 > C:\Program Files\Git\bin\git.exe branch -a -v --no-abbrev # timeout=10
      [Pipeline] }
      [Pipeline] // dir
      [Pipeline] }
      [Pipeline] // timeout
      [Pipeline] }
      [Pipeline] // timestamps
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      [BFA] Scanning build for known causes...
      [BFA] No failure causes found
      [BFA] Done. 0s
      java.lang.ArrayIndexOutOfBoundsException: 1
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.parseBranches(CliGitAPIImpl.java:1907)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getBranches(CliGitAPIImpl.java:1928)
      at hudson.plugins.git.GitAPI.getBranches(GitAPI.java:195)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2063)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
      at hudson.remoting.UserRequest.perform(UserRequest.java:205)
      at hudson.remoting.UserRequest.perform(UserRequest.java:52)
      at hudson.remoting.Request$2.run(Request.java:356)
      at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1$1.run(Engine.java:98)
      at java.lang.Thread.run(Unknown Source)
      at ......remote call to JNLP4-connect connection from 24.9.6.17/24.9.6.17:53835(Native Method)
      at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1647)
      at hudson.remoting.UserResponse.retrieve(UserRequest.java:308)
      at hudson.remoting.Channel.call(Channel.java:896)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
      at sun.reflect.GeneratedMethodAccessor713.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:498)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
      at com.sun.proxy.$Proxy111.execute(Unknown Source)
      at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1135)
      at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
      at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
      at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
      at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
      at hudson.security.ACL.impersonate(ACL.java:260)
      at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
      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:748)
      Finished: FAILURE

          [JENKINS-47196] java.lang.ArrayIndexOutOfBoundsException: 1- Source checkout issue

          Hi markewaite,

          Below single line is the exception am getting when run the pipeline project. What could be the reason for this?

          "java.lang.ArrayIndexOutOfBoundsException: 1"

          Regards,
          Vadivel Natarajan

          Vadivel Natarajan added a comment - Hi markewaite , Below single line is the exception am getting when run the pipeline project. What could be the reason for this? "java.lang.ArrayIndexOutOfBoundsException: 1" Regards, Vadivel Natarajan

          Mark Waite added a comment -

          You may need to remove the try / catch from your pipeline definition.  I don't know if groovy automatically includes a printStacktrace when it prints the value of an Exception.

           

          node {
              stage 'Checkout' {
                  checkout scm 
              }
          }

          Mark Waite added a comment - You may need to remove the try / catch from your pipeline definition.  I don't know if groovy automatically includes a printStacktrace when it prints the value of an Exception.   node { stage 'Checkout' { checkout scm } }

          Vadivel Natarajan added a comment - - edited

          Hi markewaite,

          If i remove the try catch block, I didn't get any exception.

          Regards,
          Vadivel Natarajan

          Vadivel Natarajan added a comment - - edited Hi markewaite , If i remove the try catch block, I didn't get any exception. Regards, Vadivel Natarajan

          Mark Waite added a comment - - edited

          The try/catch in your example adds no value to the pipeline. You should be able to remove it.

          I followed the instructions you provided and am unable to duplicate the problem. Refer to my JENKINS-47196 branch for the steps I've taken trying to duplicate the problem.

          Please either provide more information that will allow others to duplicate the problem, or close this bug as "Cannot reproduce".

          Mark Waite added a comment - - edited The try/catch in your example adds no value to the pipeline. You should be able to remove it. I followed the instructions you provided and am unable to duplicate the problem. Refer to my JENKINS-47196 branch for the steps I've taken trying to duplicate the problem. Please either provide more information that will allow others to duplicate the problem, or close this bug as "Cannot reproduce".

          Hi markewaite ,

          Still am getting this issue. It is occurring rarely(gaps of 1 day or 2 days) in some of our slave machines. We can't close this as not reproducible.

          Regards,

          Vadivel Natarajan 

          Vadivel Natarajan added a comment - Hi markewaite , Still am getting this issue. It is occurring rarely(gaps of 1 day or 2 days) in some of our slave machines. We can't close this as not reproducible. Regards, Vadivel Natarajan 

          Mark Waite added a comment -

          vadivel please provide the precise steps necessary to duplicate the problem on a freshly installed system. Refer to how to report a bug for the types of information needed in a bug report.

          Please provide the complete exception message (full stack trace), rather than just the single line message which your catch block is providing.

          If you can't provide precise steps to duplicate the problem on a freshly installed system, please provide a description of the alternatives you've attempted.

          Jenkins is an open source project. I work on the git plugin in my personal time. I review bug reports and create fixes and test new versions in my personal time. Any time I spend on a bug report with insufficient information is time that I cannot spend working on improvements and fixes for the larger community.

          When a bug report lacks necessary information, I tend to think that the submitter has not realized they are trying to persuade me to use my personal time for their benefit. This is your opportunity to persuade me that I should use my personal time for your benefit.

          Mark Waite added a comment - vadivel please provide the precise steps necessary to duplicate the problem on a freshly installed system. Refer to how to report a bug for the types of information needed in a bug report. Please provide the complete exception message (full stack trace), rather than just the single line message which your catch block is providing. If you can't provide precise steps to duplicate the problem on a freshly installed system, please provide a description of the alternatives you've attempted. Jenkins is an open source project. I work on the git plugin in my personal time. I review bug reports and create fixes and test new versions in my personal time. Any time I spend on a bug report with insufficient information is time that I cannot spend working on improvements and fixes for the larger community. When a bug report lacks necessary information, I tend to think that the submitter has not realized they are trying to persuade me to use my personal time for their benefit. This is your opportunity to persuade me that I should use my personal time for your benefit.

          Hi markewaite ,

          I have updated the requested environment, more error details in description. Please look into that and let me know if you need any additional details you need.

          Regards,

          Vadivel Natarajan 

          Vadivel Natarajan added a comment - Hi markewaite , I have updated the requested environment, more error details in description. Please look into that and let me know if you need any additional details you need. Regards, Vadivel Natarajan 

          Mark Waite added a comment - - edited

          Thanks for the exception details. The exception is being thrown in a line which parses the output of the command git.exe branch -a -v --no-abbrev.

          In that repository, can you provide the output of the command git.exe branch -a -v --no-abbrev?

          I expect it will show at least one line which is longer than 44 characters, includes a space character, but doesn't look like the other lines in the output. For example, a branch name or a commit message which contains an embedded control character. Branch names may not contain embedded control characters, but there have been cases (like JENKINS-34309) where an embedded control character was visible in the first line of a commit message.

          I believe that the problem you're seeing is resolved in the git-client-plugin master branch by a fix committed about 3 weeks ago. If you'd like to test drive the latest git client plugin pre-release, you can download it from ci.jenkins.io.

          If you'd like to avoid the problem without updating the plugin, find the person who is submitting commit messages in your organization which are embedding control characters in the first line of the commit message. Specifically, you'll likely find one or more commit messages with one of the line termination control characters in the commit message. The reports on earlier bugs seemed to indicate that MacOS had a way to do that from its command line.

          Mark Waite added a comment - - edited Thanks for the exception details. The exception is being thrown in a line which parses the output of the command git.exe branch -a -v --no-abbrev . In that repository, can you provide the output of the command git.exe branch -a -v --no-abbrev ? I expect it will show at least one line which is longer than 44 characters, includes a space character, but doesn't look like the other lines in the output. For example, a branch name or a commit message which contains an embedded control character. Branch names may not contain embedded control characters, but there have been cases (like JENKINS-34309 ) where an embedded control character was visible in the first line of a commit message. I believe that the problem you're seeing is resolved in the git-client-plugin master branch by a fix committed about 3 weeks ago . If you'd like to test drive the latest git client plugin pre-release, you can download it from ci.jenkins.io . If you'd like to avoid the problem without updating the plugin, find the person who is submitting commit messages in your organization which are embedding control characters in the first line of the commit message. Specifically, you'll likely find one or more commit messages with one of the line termination control characters in the commit message. The reports on earlier bugs seemed to indicate that MacOS had a way to do that from its command line.

          Mark Waite added a comment -

          Will be fixed with release of git client plugin 2.6.0

          Mark Waite added a comment - Will be fixed with release of git client plugin 2.6.0

          Mark Waite added a comment -

          Included in git client plugin 2.6.0, released 27 Oct 2017

          Mark Waite added a comment - Included in git client plugin 2.6.0, released 27 Oct 2017

            Unassigned Unassigned
            vadivel Vadivel Natarajan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: