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

Exception during gcc log parsing and warnings detection (regression)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: warnings-plugin
    • Labels:
      None
    • Environment:
      Hudson version : 1.336
      Warnings version : 2.14
      Gcc version : 3.4.6
      OS : Linux Red Hat
    • Similar Issues:

      Description

      During warnings parsing, the gcc warnings are not correctly detected.
      A gcc warnings is seen as an error and the build is set to failed (threshold set to 1 for error)
      Note that it was working correctly with Hudson 308 and Warnings 2.8

      I isolated the problem in gcc log file.
      You can find attached :

      • gcc log file
      • 2 C++ file associated with the log

      To reproduce the problem:

      • Create a Job Free Style
      • Copy in the workspace the three attached files
      • Activate the Scan of Warnings on the log file

      Results:

      • An error is incorrectly detected and failing the build (instead of detecting a warning)
      • By clicking on the detected error, the following exception is displayed:

      null
      01 hudson.util.IOException2: remote file operation failed
      02 at hudson.FilePath.act(FilePath.java:677)
      03 at hudson.FilePath.act(FilePath.java:665)
      04 at hudson.FilePath.copyTo(FilePath.java:1292)
      05 at hudson.plugins.warnings.util.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(HealthAwarePublisher.java:187)
      06 at hudson.plugins.warnings.util.HealthAwarePublisher.perform(HealthAwarePublisher.java:144)
      07 at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
      08 at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:577)
      09 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563)
      10 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:551)
      11 at hudson.model.Build$RunnerImpl.post2(Build.java:152)
      12 at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:535)
      13 at hudson.model.Run.run(Run.java:1199)
      14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      15 at hudson.model.ResourceController.execute(ResourceController.java:88)
      16 at hudson.model.Executor.run(Executor.java:123)
      17 Caused by: java.io.FileNotFoundException: In file included from my_class.cpp (No such file or directory)
      18 at java.io.FileInputStream.open(Native Method)
      19 at java.io.FileInputStream.<init>(FileInputStream.java:106)
      20 at hudson.FilePath$30.invoke(FilePath.java:1296)
      21 at hudson.FilePath$30.invoke(FilePath.java:1292)
      22 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2072)
      23 at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
      24 at hudson.FilePath.act(FilePath.java:672)
      25 ... 14 more
      26 Can't copy file from workspace to build folder: workspace=In file included from my_class.cpp, build folder=/localdata/hudson/jobs/Hudson_Issues/builds/2010-03-29_01-34-18/workspace-files/958509f5.tmp

        Attachments

          Issue Links

            Activity

            Hide
            drulli Ulli Hafner added a comment - - edited

            This has been fixed already and is part of the upcoming release 3.4.

            Show
            drulli Ulli Hafner added a comment - - edited This has been fixed already and is part of the upcoming release 3.4.
            Hide
            paskalad paskalad added a comment -

            The problem is still present by using the following configuration:
            Hudson: 1.346
            Static Analysis Utilities : 1.4
            Warnings Plug-in : 3.4

            Note that by changing the parser from GCC to GCC4, the log is correctly parsed
            which is strange because I am using GCC 3.4.6 and not GCC 4.x

            Show
            paskalad paskalad added a comment - The problem is still present by using the following configuration: Hudson: 1.346 Static Analysis Utilities : 1.4 Warnings Plug-in : 3.4 Note that by changing the parser from GCC to GCC4, the log is correctly parsed which is strange because I am using GCC 3.4.6 and not GCC 4.x
            Hide
            drulli Ulli Hafner added a comment -

            But when the issue is fixed with in the new GCC parser why don't you use it? The old parser will not be supported anymore. Maybe I should change the name of the new parser...

            Show
            drulli Ulli Hafner added a comment - But when the issue is fixed with in the new GCC parser why don't you use it? The old parser will not be supported anymore. Maybe I should change the name of the new parser...
            Hide
            paskalad paskalad added a comment -

            If the new GCC4 parser is the official GCC parser supporting all GCC version including old one like 3.4.x, yes it should be rename and the old one shall be removed to avoid ambiguity.
            But, if the goal of GCC4 parser is only to support the GCC version 4.x, the old GCC parser shall continue to be maintained and renamed GCC3, istn't it ?

            Show
            paskalad paskalad added a comment - If the new GCC4 parser is the official GCC parser supporting all GCC version including old one like 3.4.x, yes it should be rename and the old one shall be removed to avoid ambiguity. But, if the goal of GCC4 parser is only to support the GCC version 4.x, the old GCC parser shall continue to be maintained and renamed GCC3, istn't it ?
            Hide
            drulli Ulli Hafner added a comment -

            I think the new parser works with 3.x, too. It's just a new parser. I'm not sure if still someone uses the old parser (I don't use GCC at all). So maybe the best thing is to let both parsers co-exist and change the names. However, currently the display name is used to identify the parser, so changing the name is somewhat complicated without breaking existing jobs...

            Show
            drulli Ulli Hafner added a comment - I think the new parser works with 3.x, too. It's just a new parser. I'm not sure if still someone uses the old parser (I don't use GCC at all). So maybe the best thing is to let both parsers co-exist and change the names. However, currently the display name is used to identify the parser, so changing the name is somewhat complicated without breaking existing jobs...
            Hide
            paskalad paskalad added a comment -

            It is OK for me.
            I will create tickets by mentioning the GCC (eg. 3.4.x) if I found some issues on this new parser

            NB: Could you update the Wiki page to mention the specificity of the two GCC parsers ?

            Show
            paskalad paskalad added a comment - It is OK for me. I will create tickets by mentioning the GCC (eg. 3.4.x) if I found some issues on this new parser NB: Could you update the Wiki page to mention the specificity of the two GCC parsers ?

              People

              • Assignee:
                drulli Ulli Hafner
                Reporter:
                paskalad paskalad
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: