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

Exception "Illegal char" on build log event parsing

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • warnings-ng-plugin
    • None
    • Jenkins ver. 2.190.2; list of plugins attached; java.vendor AdoptOpenJDK; java.runtime.version 11.0.5+10; sun.management.compiler HotSpot 64-Bit Tiered Compilers; OS Win7x64pro
    • 7.1.1

       

       

      Actually I don't know excatly since when, but for about 2 weeks I'm facing this exception over and over again:

      2019-10-30 14:24:55 [Project 1] Searching for all files in '<WS_PATH>\<PIPELINE_NAME>' that match the pattern 'Outputs\<Project1>\Build.log'
      2019-10-30 14:24:55 [Project 1] -> found 1 file
      2019-10-30 14:24:55 [Project 1] Successfully parsed file <WS_PATH>\<PIPELINE_NAME>\Outputs\<Project1>\Build.log
      2019-10-30 14:24:55 [Project 1] -> found 2 issues (skipped 1 duplicate)
      2019-10-30 14:24:59 [Project 1] Post processing issues on 'Master' with source code encoding 'UTF-8'
      2019-10-30 14:24:59 [Project 1] Resolving absolute file names for all issues in source directories '[<WS_PATH>\<PIPELINE_NAME>]'
      2019-10-30 14:24:59 [Project 1] -> 2 resolved, 0 unresolved, 0 already resolved
      2019-10-30 14:24:59 [Project 1] Resolving module names from module definitions (build.xml, pom.xml, or Manifest.mf files)
      2019-10-30 14:24:59 [Project 1] -> resolved module names for 2 issues
      2019-10-30 14:24:59 [Project 1] Resolving package names (or namespaces) by parsing the affected files
      2019-10-30 14:24:59 [Project 1] -> resolved package names of 2 affected files
      2019-10-30 14:24:59 [Project 1] No filter has been set, publishing all 2 issues
      2019-10-30 14:24:59 [Project 1] Creating fingerprints for all affected code blocks to track issues over different builds
      2019-10-30 14:24:59 [Project 1] -> created fingerprints for 2 issues
      2019-10-30 14:24:59 [Project 1] Copying affected files to Jenkins' build folder '<JENKINS_PATH>\jobs\<PIPELINE_NAME>\builds\315\files-with-issues'
      2019-10-30 14:24:59 [Project 1] -> 0 copied, 2 not in workspace, 0 not-found, 0 with I/O error
      2019-10-30 14:24:59 [Project 2] Searching for all files in '<WS_PATH>\<PIPELINE_NAME>' that match the pattern 'Outputs\<Project2>\Build.log'
      2019-10-30 14:24:59 [Project 2] -> found 1 file
      2019-10-30 14:24:59 [Project 2] Successfully parsed file <WS_PATH>\<PIPELINE_NAME>\Outputs\<Project2>\Build.log
      2019-10-30 14:24:59 [Project 2] -> found 141 issues (skipped 141 duplicates)

      [...] skipped due to earlier failure(s) [... ]

      java.nio.file.InvalidPathException: Illegal char <*> at index 44: <PATH>/Src*** <PATH>/Source/file.c
      at java.base/sun.nio.fs.WindowsPathParser.normalize(Unknown Source)
      at java.base/sun.nio.fs.WindowsPathParser.parse(Unknown Source)
      at java.base/sun.nio.fs.WindowsPathParser.parse(Unknown Source)
      at java.base/sun.nio.fs.WindowsPath.parse(Unknown Source)
      at java.base/sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
      at java.base/java.nio.file.Path.of(Unknown Source)
      at java.base/java.nio.file.Paths.get(Unknown Source)
      at io.jenkins.plugins.analysis.core.util.AbsolutePathGenerator.resolveAbsolutePath(AbsolutePathGenerator.java:118)
      at io.jenkins.plugins.analysis.core.util.AbsolutePathGenerator.resolveAbsoluteNames(AbsolutePathGenerator.java:94)
      at io.jenkins.plugins.analysis.core.util.AbsolutePathGenerator.run(AbsolutePathGenerator.java:74)
      at io.jenkins.plugins.analysis.core.steps.IssuesScanner$ReportPostProcessor.resolveAbsolutePaths(IssuesScanner.java:321)
      at io.jenkins.plugins.analysis.core.steps.IssuesScanner$ReportPostProcessor.invoke(IssuesScanner.java:274)
      at io.jenkins.plugins.analysis.core.steps.IssuesScanner$ReportPostProcessor.invoke(IssuesScanner.java:246)
      at hudson.FilePath.act(FilePath.java:1078)
      at hudson.FilePath.act(FilePath.java:1061)
      at io.jenkins.plugins.analysis.core.steps.IssuesScanner.postProcess(IssuesScanner.java:126)
      at io.jenkins.plugins.analysis.core.steps.IssuesScanner.scan(IssuesScanner.java:110)
      at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.scanWithTool(IssuesRecorder.java:629)
      at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.record(IssuesRecorder.java:581)
      at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.perform(IssuesRecorder.java:563)
      at io.jenkins.plugins.analysis.core.steps.RecordIssuesStep$Execution.run(RecordIssuesStep.java:973)
      at io.jenkins.plugins.analysis.core.steps.RecordIssuesStep$Execution.run(RecordIssuesStep.java:936)
      at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
      at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
      at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
      at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at java.base/java.lang.Thread.run(Unknown Source)
      Finished: FAILURE

       

      I have not changed my previously working pipline script for some time. I just used to update the Jenkins and its plugins from time to time. Right now, I don't have an explanation as even the path nor the file contains any non-ASCII chars or other vorbidden once. The only thing I can tell is, that it happends, when "RecordIssus" is used to generade some charts out of a build log file.

       

      The jenkins script looks like this:

      echo "Parsing compiler warnings..."
      recordIssues(
      id: 'Build_Binary',
      name: 'Build Binary',
      sourceCodeEncoding: 'UTF-8',
      enabledForFailure: true,
      aggregatingResults: true,
      tools:
      [
      groovyScript(
      id: 'Project_1',
      name: 'Project 1',
      parserId: 'myParser',
      pattern:'04_Outputs
      <Project1>
      Build.log',
      reportEncoding:'UTF-8'
      ),
      groovyScript(
      id: 'Project_2',
      name: 'Project 2',
      parserId: 'myParser',
      pattern:'Outputs
      <Project2>
      Build.log',
      reportEncoding:'UTF-8'
      ),
      groovyScript(
      id: 'Project_3',
      name: 'Project 3',
      parserId: 'myParser',
      pattern:'Outputs
      <Project3>
      Build.log',
      reportEncoding:'UTF-8'
      ),
      groovyScript(
      id: 'Project_4',
      name: 'Project 4',
      parserId: 'myParser',
      pattern:'Outputs
      <Project4>
      Build.log',
      reportEncoding:'UTF-8'
      ),
      gcc(
      id: 'Project_5',
      name: 'Project 5',
      pattern:'Outputs
      <Project5>
      Build.log',
      reportEncoding:'UTF-8'
      )
      ]
      )

       

      I'm sorry for the obfuscation but I'm not allowed to share exact content. (I tried to keep the sense of the messages.) If you need more information please let me know.

      Thanks for your time.

          [JENKINS-59986] Exception "Illegal char" on build log event parsing

          Ulli Hafner added a comment -

          Seems that your Groovy parser does not detect a path name (<PATH>/Src** correctly. I can catch that exception, however the path will not be resolved either way, here you need to update your parser.

          Ulli Hafner added a comment - Seems that your Groovy parser does not detect a path name ( <PATH>/Src** correctly. I can catch that exception, however the path will not be resolved either way, here you need to update your parser.

          Uwe Brackenhoff added a comment - - edited

          I think I've got it:

          <PATH>/Src*** <PATH>/Source/file.c

          What happends is, that 2 cmd outputlines where mixed into each other, as the 3 asteriks are used for new compiler outputs and warnings-ng is trying to resolve a path which is a mixture of 2 pathes, which das obviously not exist. The real output looks like this:

           ***<PATH>/Source/Fi*** <PATH>/Source/File.c(110) W1020B: warning: identifier "XYZ" is undefined.

          So I need to fix the regex to handle this properly.

          Thank you very much!

          Uwe Brackenhoff added a comment - - edited I think I've got it: <PATH>/Src*** <PATH>/Source/file.c What happends is, that 2 cmd outputlines where mixed into each other, as the 3 asteriks are used for new compiler outputs and warnings-ng is trying to resolve a path which is a mixture of 2 pathes, which das obviously not exist. The real output looks like this:  ***<PATH>/Source/Fi*** <PATH>/Source/File.c(110) W1020B: warning: identifier "XYZ" is undefined. So I need to fix the regex to handle this properly. Thank you very much!

          just found http://man7.org/linux/man-pages/man1/make.1.html

          -O[type], --output-sync[=type]

          When running multiple jobs in parallel with -j, ensure the output of each job is collected together rather than interspersed with output from other jobs. If type is not specified or is target the output from the entire recipe for each target is grouped together. If type is line the output from each command line within a recipe is grouped together. If type is recurse output from an entire recursive make is grouped together. If type is none output synchronization is disabled.

          Uwe Brackenhoff added a comment - just found http://man7.org/linux/man-pages/man1/make.1.html -O [type] , --output-sync [=type] When running multiple jobs in parallel with -j, ensure the output of each job is collected together rather than interspersed with output from other jobs. If type is not specified or is target the output from the entire recipe for each target is grouped together. If type is line the output from each command line within a recipe is grouped together. If type is recurse output from an entire recursive make is grouped together. If type is none output synchronization is disabled.

          Ulli Hafner added a comment -

          Is it not working?

          Ulli Hafner added a comment - Is it not working?

          Sorry, my intention was to close this ticket. Seams like I've misunderstood your workflow.

          Actually I've decided to use the make switch to avoid interleaved cmd output at all and therefore remove the root of the evil. As Jenkins is running overnight, there is no need for "the highest build perfomance".

           

          But thank you very mutch to point me out to the root cause and of cause for the fix implementation.

          Uwe Brackenhoff added a comment - Sorry, my intention was to close this ticket. Seams like I've misunderstood your workflow. Actually I've decided to use the make switch to avoid interleaved cmd output at all and therefore remove the root of the evil. As Jenkins is running overnight, there is no need for "the highest build perfomance".   But thank you very mutch to point me out to the root cause and of cause for the fix implementation.

          Ulli Hafner added a comment -

          Ah, then we use "Close" to close the issue...

          Ulli Hafner added a comment - Ah, then we use "Close" to close the issue...

          Can't be afforded... to simple...

           

          Have a nice day

          Uwe Brackenhoff added a comment - Can't be afforded... to simple...   Have a nice day

            drulli Ulli Hafner
            ubra42 Uwe Brackenhoff
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: