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

org.jvnet.winp.WinpException: Failed to read RT_USER_PROCESS_PARAMETERS

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Windows Server 2008R2
      Jenkins 2.7.4
      git-plugin 3.0.0

      java version "1.8.0_31"
      Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
    • Similar Issues:

      Description

      A project simply configured to retrieve from Git and build using MSBuild. The job is not able to successfully retrieve the code from Git, giving the error shown below.

      If I open a command line, CD to the workspace path, and run exactly the same command "git.exe fetch --tags --progress https://path.to.repo/gitfile.git +refs/heads/:refs/remotes/origin/" there is absolutely no problem and the command executes successfully.

      I have tried running the Jenkins service as both "Local System Account", and as the Administrator user on the machine - restarting the service when changing the user. Both cases give the same error.

      Started by user Admin
      Building in workspace C:\Program Files (x86)\Jenkins\workspace\Build and Deploy Plugins - Dev
      > git.exe rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
      > git.exe config remote.origin.url https://path.to.repo/gitfile.git # timeout=10
      Fetching upstream changes from https://path.to.repo/gitfile.git
      > git.exe --version # timeout=10
      using GIT_ASKPASS to set credentials ***
      > git.exe fetch --tags --progress https://path.to.repo/gitfile.git +refs/heads/:refs/remotes/origin/
      ERROR: Timeout after 10 minutes
      ERROR: Failed to join a process
      org.jvnet.winp.WinpException: Failed to read RT_USER_PROCESS_PARAMETERS error=299 at .\envvar-cmdline.cpp:151
      at org.jvnet.winp.Native.getCmdLineAndEnvVars(Native Method)
      at org.jvnet.winp.WinProcess.parseCmdLineAndEnvVars(WinProcess.java:126)
      at org.jvnet.winp.WinProcess.getCommandLine(WinProcess.java:102)
      at hudson.util.ProcessTree$Windows$1.getArguments(ProcessTree.java:441)
      at hudson.plugins.msbuild.MsBuildKillingVeto.vetoProcessKilling(MsBuildKillingVeto.java:55)
      at hudson.util.ProcessTree$OSProcess.getVeto(ProcessTree.java:239)
      at hudson.util.ProcessTree$Windows$1.killRecursively(ProcessTree.java:422)
      at hudson.util.ProcessTree.killAll(ProcessTree.java:142)
      at hudson.Proc$LocalProc.destroy(Proc.java:375)
      at hudson.Proc$LocalProc.kill(Proc.java:367)
      at hudson.Proc$1.run(Proc.java:157)
      at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
      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 java.lang.Thread.run(Unknown Source)
      ERROR: Error fetching remote repo 'origin'
      hudson.plugins.git.GitException: Failed to fetch from https://path.to.repo/gitfile.git
      at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:797)
      at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1051)
      at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1082)
      at hudson.scm.SCM.checkout(SCM.java:495)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
      at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
      at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
      at hudson.model.Run.execute(Run.java:1741)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      at hudson.model.ResourceController.execute(ResourceController.java:98)
      at hudson.model.Executor.run(Executor.java:410)
      Caused by: hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress https://path.to.repo/gitfile.git +refs/heads/:refs/remotes/origin/" returned status code -1073741510:
      stdout:
      stderr:
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1752)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1495)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:64)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:315)
      at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:795)
      ... 11 more
      ERROR: null
      Finished: FAILURE

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          That timeout message is typically caused by an authentication failure and command line git waiting for the correct username and/or password to be provided.

          If you're using TFS as your git server, then this may be a duplicate of JENKINS-38138 or JENKINS-38179. In that case, the work around is to downgrade to git plugin 2.6.0 and git client plugin 1.21.0.

          If you're using TFS as your git server and switched to jgit and the authentication still fails, then that may mean that you need the "jgitapache" git implementation which was just merged to the git client plugin through the work of Olivier Dagenais on JENKINS-37934. In that case, the work around might be to install a pre-release version of what will eventually be git client plugin 2.1.0, then add jgitapache as a valid git implementation and use it in your job definition.

          If you're not using TFS, but have special characters in the password of the specific user (like caret or ampersand or single quote or double quote), then this may be a duplicate of JENKINS-38194. The work around in that case may be to switch that job from using the command line git implementation to use the JGit implementation. The JGit implementation needs to be enabled globally first from "Manage Jenkins", "Global Tool Configuration", "Git", then there will be a pick list in each job which will allow you to choose whether that job should use command line git or JGit.

          Another work around in some cases is to switch the job from using https based cloning to using ssh based cloning. That usually changes the URL from an https form to either git@hostname:directory or ssh://user@hostname/directory .

          As a side note, the Java 8 version you're using was released over 18 months ago. I doubt the Java 8 version that will have any impact on this particular problem, since the timeout came from command line git and that usually indicates an authentication failure. However, 18 months is quite a long time in the world of JDK patches. There have been several releases since then which might matter to you. I'm not aware of any specific problems with that Java 8 version, but I only test with Java 8 builds 101 and 102, not with Java 8 build 31.

          Show
          markewaite Mark Waite added a comment - - edited That timeout message is typically caused by an authentication failure and command line git waiting for the correct username and/or password to be provided. If you're using TFS as your git server, then this may be a duplicate of JENKINS-38138 or JENKINS-38179 . In that case, the work around is to downgrade to git plugin 2.6.0 and git client plugin 1.21.0. If you're using TFS as your git server and switched to jgit and the authentication still fails, then that may mean that you need the "jgitapache" git implementation which was just merged to the git client plugin through the work of Olivier Dagenais on JENKINS-37934 . In that case, the work around might be to install a pre-release version of what will eventually be git client plugin 2.1.0, then add jgitapache as a valid git implementation and use it in your job definition. If you're not using TFS, but have special characters in the password of the specific user (like caret or ampersand or single quote or double quote), then this may be a duplicate of JENKINS-38194 . The work around in that case may be to switch that job from using the command line git implementation to use the JGit implementation. The JGit implementation needs to be enabled globally first from "Manage Jenkins", "Global Tool Configuration", "Git", then there will be a pick list in each job which will allow you to choose whether that job should use command line git or JGit. Another work around in some cases is to switch the job from using https based cloning to using ssh based cloning. That usually changes the URL from an https form to either git@hostname:directory or ssh://user@hostname/directory . As a side note, the Java 8 version you're using was released over 18 months ago. I doubt the Java 8 version that will have any impact on this particular problem, since the timeout came from command line git and that usually indicates an authentication failure. However, 18 months is quite a long time in the world of JDK patches. There have been several releases since then which might matter to you. I'm not aware of any specific problems with that Java 8 version, but I only test with Java 8 builds 101 and 102, not with Java 8 build 31.
          Hide
          benpwp Ben Empson added a comment -

          Resolved by updating to jGit - thank you!! FYI the chars _ and ! are present in the password.

          Will update the JVM

          Show
          benpwp Ben Empson added a comment - Resolved by updating to jGit - thank you!! FYI the chars _ and ! are present in the password. Will update the JVM
          Hide
          markewaite Mark Waite added a comment -

          Can you further clarify which (if any) of the scenarios described in my first comment apply in your case?

          Are you using TFS?

          Are _ and ! the only special characters in the password?

          Any other hints that would allow someone else to duplicate the problem (and thus be sure it is fixed in some future release)?

          Show
          markewaite Mark Waite added a comment - Can you further clarify which (if any) of the scenarios described in my first comment apply in your case? Are you using TFS? Are _ and ! the only special characters in the password? Any other hints that would allow someone else to duplicate the problem (and thus be sure it is fixed in some future release)?
          Hide
          benpwp Ben Empson added a comment - - edited

          The scenario is not using TFS with special chars in the password. Yes, _ and ! were the only special chars present. No other hints - this was a vanilla installation and the first project I setup in it. Changing to JGit resolved the problem. I believe that the remote git server is Linux but it's a 3rd-party service. Seems likely that this is a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-38194 - I note that the error stacktrace shows the use of GIT_ASKPASS in my scenario also - this was mentioned in 38194.

          Show
          benpwp Ben Empson added a comment - - edited The scenario is not using TFS with special chars in the password. Yes, _ and ! were the only special chars present. No other hints - this was a vanilla installation and the first project I setup in it. Changing to JGit resolved the problem. I believe that the remote git server is Linux but it's a 3rd-party service. Seems likely that this is a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-38194 - I note that the error stacktrace shows the use of GIT_ASKPASS in my scenario also - this was mentioned in 38194.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            benpwp Ben Empson
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: