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

Perforce plugin issues wrong error message when exception occurs on remote end

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • None
    • Windows

      When there is an error in the global configuration that injects broken environment variables (blank name for the variable) the Perforce-plugin fails with:

      Started by user testuser
      [EnvInject] - Loading node environment variables.
      Building remotely on testslave in workspace E:\build_e\workspace\Test_Component
      Using remote perforce client: testclient-12345678
      [Test_Component] $ C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678
      Caught exception communicating with perforce. No output for: C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678 com.tek42.perforce.PerforceException: No output for: C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678
      at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:384)
      at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292)
      at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:61)
      at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1528)
      at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1489)
      at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:795)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
      at hudson.model.Run.run(Run.java:1408)
      at hudson.model.Build.run(Build.java:110)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:238)
      ERROR: Unable to communicate with perforce. No output for: C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678
      Finished: FAILURE

      The correct error would be something like, can't "run the command".
      Because the actual error is something like:

      Caused by: java.io.IOException: Cannot run program "cmd.exe" (in directory "E:\build_e\workspace\Test_Component"): CreateProcess error=87, The parameter is incorrect

      at java.lang.ProcessBuilder.start(Unknown Source)

      at hudson.Proc$LocalProc.<init>(Proc.java:244)

          [JENKINS-15904] Perforce plugin issues wrong error message when exception occurs on remote end

          Markus Strand added a comment -

          The error handling completely hides certain types of errors, and just says 'No output for...'

          src\main\java\com\tek42\perforce\parse\AbstractPerforceTemplate.java:
          throw new PerforceException("No output for: " + debugCmd);

          Markus Strand added a comment - The error handling completely hides certain types of errors, and just says 'No output for...' src\main\java\com\tek42\perforce\parse\AbstractPerforceTemplate.java: throw new PerforceException("No output for: " + debugCmd);

          Rob Petti added a comment -

          Yes, but how do you know what the actual exception is?

          Rob Petti added a comment - Yes, but how do you know what the actual exception is?

          Rob Petti added a comment -

          Updating ticket summary, since this is a pretty general problem it seems. It's not so much that it's 'hiding' errors, as it can't send exceptions back from the remote slave agent using the current implementation. The only notion that the master has that something is wrong is the lack of data being returned.

          I'd like to know how you are able to view the actual exception. It may help us find a way to transfer that exception back to the master and report it correctly.

          Rob Petti added a comment - Updating ticket summary, since this is a pretty general problem it seems. It's not so much that it's 'hiding' errors, as it can't send exceptions back from the remote slave agent using the current implementation. The only notion that the master has that something is wrong is the lack of data being returned. I'd like to know how you are able to view the actual exception. It may help us find a way to transfer that exception back to the master and report it correctly.

          Markus Strand added a comment -

          Our engineers are trying to isolate from our private branch the changes needed to show the actual exception.
          It basically catches the possible errors in calling the command.

          Markus Strand added a comment - Our engineers are trying to isolate from our private branch the changes needed to show the actual exception. It basically catches the possible errors in calling the command.

          Jesse Glick added a comment -

          Jesse Glick added a comment - Exploratory diagnostic patch: https://github.com/jenkinsci/perforce-plugin/pull/34

          Jesse Glick added a comment -

          Regarding https://github.com/jenkinsci/perforce-plugin/pull/34#issuecomment-24535270 discussion, is there still a problem with RemoteLauncher in current versions of Jenkins, and if so is this filed?

          Jesse Glick added a comment - Regarding https://github.com/jenkinsci/perforce-plugin/pull/34#issuecomment-24535270 discussion, is there still a problem with RemoteLauncher in current versions of Jenkins, and if so is this filed?

          Rob Petti added a comment -

          We need the streams to be closed correctly after the command has finished executing and this was not happening on slaves back then, which is part of what prompted me to re-implement it.

          I don't believe it's an issue in current versions, but I could be mistaken. I haven't had the chance to try it again.

          In any case, we still support pre-fork versions of Hudson, so the current code will likely need to stay put for now... We might just need to catch any IOExceptions in the RemoteCall, and pass them back over the channel by hand.

          Rob Petti added a comment - We need the streams to be closed correctly after the command has finished executing and this was not happening on slaves back then, which is part of what prompted me to re-implement it. I don't believe it's an issue in current versions, but I could be mistaken. I haven't had the chance to try it again. In any case, we still support pre-fork versions of Hudson, so the current code will likely need to stay put for now... We might just need to catch any IOExceptions in the RemoteCall, and pass them back over the channel by hand.

          Jesse Glick added a comment -

          Is it possible to use HudsonP4DefaultExecutor unconditionally on (at least recent versions of) Jenkins, while continuing to use HudsonP4RemoteExecutor for Hudson? That would at least reduce the number of people affected by the bug.

          Jesse Glick added a comment - Is it possible to use HudsonP4DefaultExecutor unconditionally on (at least recent versions of) Jenkins, while continuing to use HudsonP4RemoteExecutor for Hudson? That would at least reduce the number of people affected by the bug.

          Rob Petti added a comment -

          Possibly. We'd need to determine exactly which versions work with it, however. It's probably not something that was fixed in the first release of Jenkins.

          Rob Petti added a comment - Possibly. We'd need to determine exactly which versions work with it, however. It's probably not something that was fixed in the first release of Jenkins.

          Jesse Glick added a comment -

          FYI, while working with a user who was running into this “blank” error, I suggested they run with

          https://github.com/jglick/perforce-plugin/commit/64193675fb345eaf6793518c93c69e21f22b4cb9

          When they did, they started getting a meaningful error message

          java.io.IOException: Cannot run program "/some/Unix/path/to/p4" (in directory "e:\jenkins\workspace\some\job"): CreateProcess error=2, The system cannot find the file specified
          

          which immediately led to diagnosis of the problem: P4 installations not configured correctly for Windows vs. Unix. When they corrected their configuration, everything worked (presumably using the patched plugin which always uses HudsonP4DefaultExecutor).

          Another customer who was receiving the blank error began using the patched plugin and then got

          Cannot run program "p4" (in directory "c:\hudson\workspace\…"): CreateProcess error=87, The parameter is incorrect 
          

          which is still rather mysterious but at least focuses the problem on a Win32 error of some kind (e.g. bad environment variables).

          So I would again suggest that HudsonP4DefaultExecutor be used at least on modern Jenkins systems.

          Jesse Glick added a comment - FYI, while working with a user who was running into this “blank” error, I suggested they run with https://github.com/jglick/perforce-plugin/commit/64193675fb345eaf6793518c93c69e21f22b4cb9 When they did, they started getting a meaningful error message java.io.IOException: Cannot run program "/some/Unix/path/to/p4" (in directory "e:\jenkins\workspace\some\job"): CreateProcess error=2, The system cannot find the file specified which immediately led to diagnosis of the problem: P4 installations not configured correctly for Windows vs. Unix. When they corrected their configuration, everything worked (presumably using the patched plugin which always uses HudsonP4DefaultExecutor ). Another customer who was receiving the blank error began using the patched plugin and then got Cannot run program "p4" (in directory "c:\hudson\workspace\…"): CreateProcess error=87, The parameter is incorrect which is still rather mysterious but at least focuses the problem on a Win32 error of some kind (e.g. bad environment variables). So I would again suggest that HudsonP4DefaultExecutor be used at least on modern Jenkins systems.

            Unassigned Unassigned
            strand Markus Strand
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: