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

`java.lang.NullPointerException because "pattern" is null` on 2.3.1

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • log-parser-plugin
    • None

      Beginning with version 2.3.1 The following error appears in the Jenkins Console and in the Agent err log, this is not reproduced in 2.3.0.

      Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from REDACTED:59435
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1784)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
at hudson.remoting.Channel.call(Channel.java:1000)
at hudson.plugins.logparser.LogParserParser.parseLogBody(LogParserParser.java:348)
at hudson.plugins.logparser.LogParserParser.parseLog(LogParserParser.java:161)
at hudson.plugins.logparser.LogParserPublisher.perform(LogParserPublisher.java:120)
at jenkins.tasks.SimpleBuildStep.perform(SimpleBuildStep.java:123)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:101)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:71)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
Also: org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: 42f10337-f6e6-411a-a795-e72fb8140fc5
java.lang.NullPointerException
at hudson.plugins.logparser.ClassicParsingStrategy.getLineStatusMatches(ClassicParsingStrategy.java:128)
at hudson.plugins.logparser.ClassicParsingStrategy.parse(ClassicParsingStrategy.java:103)
at hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:73)
at hudson.plugins.logparser.LogParserStatusComputer.call(LogParserStatusComputer.java:54)
at hudson.plugins.logparser.LogParserStatusComputer.call(LogParserStatusComputer.java:12)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:377)
at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:125)
at java.base/java.lang.Thread.run(Thread.java:833)
Finished: FAILURE

       

      INFO: LogParserThread: Start parsing log part 0
Exception in thread "pool-105-thread-1" java.lang.NullPointerException: Cannot invoke "java.util.regex.Pattern.matcher(java.lang.CharSequence)" because "pattern" is null
    at hudson.plugins.logparser.LineToStatus.apply(LineToStatus.java:35)
    at hudson.plugins.logparser.LogParserThread.getLineStatus(LogParserThread.java:107)
    at hudson.plugins.logparser.LogParserThread.getLineStatuses(LogParserThread.java:89)
    at hudson.plugins.logparser.LogParserThread.run(LogParserThread.java:39)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:833)

          [JENKINS-72311] `java.lang.NullPointerException because "pattern" is null` on 2.3.1

          Thien Le Dinh added a comment -

          I downgraded  Log Parser plugin to 2.3.0, it worked 

          Thien Le Dinh added a comment - I downgraded  Log Parser plugin to 2.3.0, it worked 

          Steven Wadsworth added a comment - - edited

          I saw the same problem and downgraded the plugin on the production system.  I did investigate further and found that the job that was failing was using "default_rules" and that file was unchanged in about three years.  The file must have either been copied from some source or was from a previous installation, and it contained a newline in the middle of a comment.  The section should have looked like this:

          #each line containing 'BUILD' represents the start of a section for grouping errors and warnings found after the line.

          #also creates a quick access link.
          start /BUILD/

          The first comment line instead was split into this:

          #each line containing 'BUILD' represents the start of a section for grouping e
          rrors and warnings found after the line.

          It seems the update is no longer tolerating what is seen as a bad rule.

          I updated to the latest again and confirmed builds back to back with the good and bad rules file.  The latest version does work correctly with a valid rules file.

          Edited to fix overzealous formatting of text by Jira.

          Steven Wadsworth added a comment - - edited I saw the same problem and downgraded the plugin on the production system.  I did investigate further and found that the job that was failing was using "default_rules" and that file was unchanged in about three years.  The file must have either been copied from some source or was from a previous installation, and it contained a newline in the middle of a comment.  The section should have looked like this: #each line containing 'BUILD' represents the start of a section for grouping errors and warnings found after the line. #also creates a quick access link. start /BUILD/ The first comment line instead was split into this: #each line containing 'BUILD' represents the start of a section for grouping e rrors and warnings found after the line. It seems the update is no longer tolerating what is seen as a bad rule. I updated to the latest again and confirmed builds back to back with the good and bad rules file.  The latest version does work correctly with a valid rules file. Edited to fix overzealous formatting of text by Jira.

          Kyle added a comment -

          In our case we had a missing forward slash at the end of a line.

           # Suppress errors that are within comments
-ok /\\\\.*error*$
+ok /\\\\.*error*$/

          Kyle added a comment - In our case we had a missing forward slash at the end of a line. # Suppress errors that are within comments -ok /\\\\.*error*$ +ok /\\\\.*error*$/

            mreinhardt Martin Reinhardt
            kgott_at_ao Kyle
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: