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

Exception during gcc log parsing and warnings detection (regression)

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • warnings-plugin
    • None
    • Hudson version : 1.336
      Warnings version : 2.14
      Gcc version : 3.4.6
      OS : Linux Red Hat

    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

          depends on

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-4753 gcc warnings not parsed correctly

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            drulli Ulli Hafner added a comment - - edited

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

            drulli Ulli Hafner added a comment - - edited This has been fixed already and is part of the upcoming release 3.4.
            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

            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
            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...

            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...
            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 ?

            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 ?
            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...

            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...
            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 ?

            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

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

              Dates

                Created:
                Updated:
                Resolved: