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

null pointer exception during text finder processing of old job definition

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Component/s: text-finder-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.235.4 with text-finder 1.15 using a job that was originally created with text-finder 1.12
    • Similar Issues:

      Description

      I have a job defined with text-finder 1.12 settings to mark the build unstable if the text was found in the console log. When I run that job with text-finder 1.15, a null pointer exception is reported like this:

      BUILD SUCCESSFUL
      Total time: 0 seconds
      ERROR: Build step failed with exception
      java.lang.NullPointerException
      	at hudson.plugins.textfinder.TextFinderPublisher.perform(TextFinderPublisher.java:248)
      	at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78)
      	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:741)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
      	at hudson.model.Build$BuildExecution.post2(Build.java:186)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
      	at hudson.model.Run.execute(Run.java:1905)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      	at hudson.model.ResourceController.execute(ResourceController.java:97)
      	at hudson.model.Executor.run(Executor.java:428)
      Build step 'Search files or the console log for regular expression(s)' marked build as failure
      Finished: FAILURE
      

      If I save the job and run it again it succeeds. Since the workaround is so simple, I don't know that this is worth any time to fix it. I'm submitting the issue to document it just in case others encounter the same issue.

        Attachments

          Activity

          Hide
          basil Basil Crow added a comment -

          Hi Mark Waite, sorry to hear you're still having problems with this plugin. However, I am at a loss as to why this problem is occurring. This case is explicitly handled in the TextFinderPublisher#readResolve code, and there is even a test for this behavior in TextFinderPublisherFreestyleCompatibilityTest#persistedConfigurationBeforeMultipleFinders. I even tried running this test with the exact job configuration from 1.12 that you provided, and the readResolve method correctly deserialized your job into the new format. Can you try adjusting that test to reproduce your failure, or setting a breakpoint in TextFinderPublisher#readResolve and letting me know why it's not deserializing properly? The stack trace should look like this in the normal case:

          setTextFinders:125, TextFinderPublisher (hudson.plugins.textfinder)
          readResolve:204, TextFinderPublisher (hudson.plugins.textfinder)
          invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
          invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
          invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
          invoke:566, Method (java.lang.reflect)
          callReadResolve:66, SerializationMethodInvoker (com.thoughtworks.xstream.converters.reflection)
          unmarshal:271, RobustReflectionConverter (hudson.util)
          convert:72, TreeUnmarshaller (com.thoughtworks.xstream.core)
          convert:65, AbstractReferenceUnmarshaller (com.thoughtworks.xstream.core)
          convertAnother:66, TreeUnmarshaller (com.thoughtworks.xstream.core)
          convertAnother:50, TreeUnmarshaller (com.thoughtworks.xstream.core)
          readItem:71, AbstractCollectionConverter (com.thoughtworks.xstream.converters.collections)
          unmarshal:197, CopyOnWriteList$ConverterImpl (hudson.util)
          unmarshal:275, DescribableList$ConverterImpl (hudson.util)
          convert:72, TreeUnmarshaller (com.thoughtworks.xstream.core)
          convert:65, AbstractReferenceUnmarshaller (com.thoughtworks.xstream.core)
          convertAnother:66, TreeUnmarshaller (com.thoughtworks.xstream.core)
          unmarshalField:393, RobustReflectionConverter (hudson.util)
          doUnmarshal:331, RobustReflectionConverter (hudson.util)
          unmarshal:270, RobustReflectionConverter (hudson.util)
          convert:72, TreeUnmarshaller (com.thoughtworks.xstream.core)
          convert:65, AbstractReferenceUnmarshaller (com.thoughtworks.xstream.core)
          convertAnother:66, TreeUnmarshaller (com.thoughtworks.xstream.core)
          convertAnother:50, TreeUnmarshaller (com.thoughtworks.xstream.core)
          start:134, TreeUnmarshaller (com.thoughtworks.xstream.core)
          unmarshal:32, AbstractTreeMarshallingStrategy (com.thoughtworks.xstream.core)
          unmarshal:1189, XStream (com.thoughtworks.xstream)
          unmarshal:161, XStream2 (hudson.util)
          unmarshal:132, XStream2 (hudson.util)
          unmarshal:1173, XStream (com.thoughtworks.xstream)
          fromXML:1053, XStream (com.thoughtworks.xstream)
          read:147, XmlFile (hudson)
          load:372, Items (hudson.model)
          run:3166, Jenkins$14 (jenkins.model)
          run:169, TaskGraphBuilder$TaskImpl (org.jvnet.hudson.reactor)
          runTask:296, Reactor (org.jvnet.hudson.reactor)
          runTask:1096, Jenkins$5 (jenkins.model)
          run:214, Reactor$2 (org.jvnet.hudson.reactor)
          run:117, Reactor$Node (org.jvnet.hudson.reactor)
          runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
          run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
          run:834, Thread (java.lang)
          
          Show
          basil Basil Crow added a comment - Hi Mark Waite , sorry to hear you're still having problems with this plugin. However, I am at a loss as to why this problem is occurring. This case is explicitly handled in the TextFinderPublisher#readResolve code, and there is even a test for this behavior in TextFinderPublisherFreestyleCompatibilityTest#persistedConfigurationBeforeMultipleFinders . I even tried running this test with the exact job configuration from 1.12 that you provided, and the readResolve method correctly deserialized your job into the new format. Can you try adjusting that test to reproduce your failure, or setting a breakpoint in TextFinderPublisher#readResolve and letting me know why it's not deserializing properly? The stack trace should look like this in the normal case: setTextFinders:125, TextFinderPublisher (hudson.plugins.textfinder) readResolve:204, TextFinderPublisher (hudson.plugins.textfinder) invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect) invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect) invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect) invoke:566, Method (java.lang.reflect) callReadResolve:66, SerializationMethodInvoker (com.thoughtworks.xstream.converters.reflection) unmarshal:271, RobustReflectionConverter (hudson.util) convert:72, TreeUnmarshaller (com.thoughtworks.xstream.core) convert:65, AbstractReferenceUnmarshaller (com.thoughtworks.xstream.core) convertAnother:66, TreeUnmarshaller (com.thoughtworks.xstream.core) convertAnother:50, TreeUnmarshaller (com.thoughtworks.xstream.core) readItem:71, AbstractCollectionConverter (com.thoughtworks.xstream.converters.collections) unmarshal:197, CopyOnWriteList$ConverterImpl (hudson.util) unmarshal:275, DescribableList$ConverterImpl (hudson.util) convert:72, TreeUnmarshaller (com.thoughtworks.xstream.core) convert:65, AbstractReferenceUnmarshaller (com.thoughtworks.xstream.core) convertAnother:66, TreeUnmarshaller (com.thoughtworks.xstream.core) unmarshalField:393, RobustReflectionConverter (hudson.util) doUnmarshal:331, RobustReflectionConverter (hudson.util) unmarshal:270, RobustReflectionConverter (hudson.util) convert:72, TreeUnmarshaller (com.thoughtworks.xstream.core) convert:65, AbstractReferenceUnmarshaller (com.thoughtworks.xstream.core) convertAnother:66, TreeUnmarshaller (com.thoughtworks.xstream.core) convertAnother:50, TreeUnmarshaller (com.thoughtworks.xstream.core) start:134, TreeUnmarshaller (com.thoughtworks.xstream.core) unmarshal:32, AbstractTreeMarshallingStrategy (com.thoughtworks.xstream.core) unmarshal:1189, XStream (com.thoughtworks.xstream) unmarshal:161, XStream2 (hudson.util) unmarshal:132, XStream2 (hudson.util) unmarshal:1173, XStream (com.thoughtworks.xstream) fromXML:1053, XStream (com.thoughtworks.xstream) read:147, XmlFile (hudson) load:372, Items (hudson.model) run:3166, Jenkins$14 (jenkins.model) run:169, TaskGraphBuilder$TaskImpl (org.jvnet.hudson.reactor) runTask:296, Reactor (org.jvnet.hudson.reactor) runTask:1096, Jenkins$5 (jenkins.model) run:214, Reactor$2 (org.jvnet.hudson.reactor) run:117, Reactor$Node (org.jvnet.hudson.reactor) runWorker:1128, ThreadPoolExecutor (java.util.concurrent) run:628, ThreadPoolExecutor$Worker (java.util.concurrent) run:834, Thread (java.lang)
          Hide
          markewaite Mark Waite added a comment - - edited

          Thanks for your diligence Basil Crow. Because the work around is so easy, I'd rather close this as "Won't fix" than spend time investigating it.

          I have many jobs that use text finder and have version 1.12 configurations that are upgraded by the readResolve and only one of those jobs had this issue.

          Show
          markewaite Mark Waite added a comment - - edited Thanks for your diligence Basil Crow . Because the work around is so easy, I'd rather close this as "Won't fix" than spend time investigating it. I have many jobs that use text finder and have version 1.12 configurations that are upgraded by the readResolve and only one of those jobs had this issue.
          Hide
          basil Basil Crow added a comment -

          I have many jobs that use text finder and have version 1.12 configurations that are upgraded by the readResolve and only one of those jobs had this issue.

          Thanks, Mark Waite. And I assume this was the job you linked to above?

          Show
          basil Basil Crow added a comment - I have many jobs that use text finder and have version 1.12 configurations that are upgraded by the readResolve and only one of those jobs had this issue. Thanks, Mark Waite . And I assume this was the job you linked to above?
          Hide
          markewaite Mark Waite added a comment -

          Yes, that is the job that shows the issue.

          Show
          markewaite Mark Waite added a comment - Yes, that is the job that shows the issue.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            markewaite Mark Waite
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: