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

Compiler warnings from console miscalculated if console annotation is used

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • warnings-plugin
    • None
    • Jenkins 1.409.2, Warnings plugin 3.22, Timestamper 1.2.2, Eclipse compiler parser

    Description

      When one has console annotations enabled (e.g. via the Timestamper plugin), the warnings count is (sometimes) miscalculated. And worse: the warnings change from build to build without code changes.

      Warnings look the e.g. like this:

      DataProviderHelper.java:80, Eclipse Java Compiler, Priority: Normal

      [8mha:AAAAdB+LCAAAAAAAAABb85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgZGLwaB3MycnMzi4My85FTXgvzkjIoiBimoScn5ecX5Oal6zhAaVS9DRQGQNu5k0LsPAPYXhGGBAAAA[0mPropertyModel is a raw type. References to generic type PropertyModel should be parameterized

      DataProviderHelper.java:80, Eclipse Java Compiler, Priority: Normal

      [8mha:AAAAdB+LCAAAAAAAAABb85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgZGLwaB3MycnMzi4My85FTXgvzkjIoiBimoScn5ecX5Oal6zhAaVS9DRQGQNu5k0HsAAMs64teBAAAA[0mPropertyModel is a raw type. References to generic type PropertyModel should be parameterized

      The plugin doesn't seem to recognize the 2 warnings as duplicate and therefore counts them as 2 warnings

      Attachments

        Issue Links

          Activity

            kutzi kutzi added a comment -

            I just managed to get a stack trace of a job 'hanging' in the parsing phase and it seems to support the hypothesis:

            "Executor #1 for tooltime : executing INT_TESTS_TRUNK #1624" prio=10 tid=0x000000004fea2800 nid=0x3692 runnable [0x00000000449af000]
            java.lang.Thread.State: RUNNABLE
            at java.util.Arrays.copyOfRange(Arrays.java:3209)
            at java.lang.String.<init>(String.java:215)
            at java.lang.StringBuilder.toString(StringBuilder.java:430)
            at hudson.console.ConsoleNote.removeNotes(ConsoleNote.java:308)
            at hudson.plugins.warnings.parser.RegexpDocumentParser.parse(RegexpDocumentParser.java:47)
            at hudson.plugins.warnings.parser.ParserRegistry.parse(ParserRegistry.java:271)
            at hudson.plugins.warnings.WarningsPublisher.parseConsoleLog(WarningsPublisher.java:266)
            at hudson.plugins.warnings.WarningsPublisher.perform(WarningsPublisher.java:241)
            at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:312)
            at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27)
            at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:649)
            at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:625)
            at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:881)
            at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:572)
            at hudson.model.Run.run(Run.java:1386)
            at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
            at hudson.model.ResourceController.execute(ResourceController.java:88)
            at hudson.model.Executor.run(Executor.java:145)

            kutzi kutzi added a comment - I just managed to get a stack trace of a job 'hanging' in the parsing phase and it seems to support the hypothesis: "Executor #1 for tooltime : executing INT_TESTS_TRUNK #1624" prio=10 tid=0x000000004fea2800 nid=0x3692 runnable [0x00000000449af000] java.lang.Thread.State: RUNNABLE at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.<init>(String.java:215) at java.lang.StringBuilder.toString(StringBuilder.java:430) at hudson.console.ConsoleNote.removeNotes(ConsoleNote.java:308) at hudson.plugins.warnings.parser.RegexpDocumentParser.parse(RegexpDocumentParser.java:47) at hudson.plugins.warnings.parser.ParserRegistry.parse(ParserRegistry.java:271) at hudson.plugins.warnings.WarningsPublisher.parseConsoleLog(WarningsPublisher.java:266) at hudson.plugins.warnings.WarningsPublisher.perform(WarningsPublisher.java:241) at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:312) at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:649) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:625) at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:881) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:572) at hudson.model.Run.run(Run.java:1386) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145)
            drulli Ulli Hafner added a comment -

            The main problem is, that the Eclipse parser needs to parse multiple lines, which makes that much more difficult...

            drulli Ulli Hafner added a comment - The main problem is, that the Eclipse parser needs to parse multiple lines, which makes that much more difficult...
            kutzi kutzi added a comment -

            But maybe it's possible to just remove the annotations per-line? Don't know much about console annotations, so I cannot say if it's a valid assumption that an annotation never spans multiple lines.

            kutzi kutzi added a comment - But maybe it's possible to just remove the annotations per-line? Don't know much about console annotations, so I cannot say if it's a valid assumption that an annotation never spans multiple lines.
            drulli Ulli Hafner added a comment -

            This will not help. In order to parse Eclipse warnings the console log needs to be filtered. And the regexp scanner works on the whole string (including linebreaks).

            drulli Ulli Hafner added a comment - This will not help. In order to parse Eclipse warnings the console log needs to be filtered. And the regexp scanner works on the whole string (including linebreaks).
            kutzi kutzi added a comment -

            I mean something like this:
            https://github.com/jenkinsci/warnings-plugin/pull/4

            It shouldn't affect the parsers, but avoid copying huge strings again and again

            kutzi kutzi added a comment - I mean something like this: https://github.com/jenkinsci/warnings-plugin/pull/4 It shouldn't affect the parsers, but avoid copying huge strings again and again

            People

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

              Dates

                Created:
                Updated:
                Resolved: