Is it possible that you updated analysis-model to 9.0.0 and then run a build before you updated to warnings 8.4.2? In those builds the serialization was broken. So it should disappear if you delete these builds and retry. See https://github.com/jenkinsci/warnings-ng-plugin/releases/tag/v8.4.2

I upgraded to analysis model api plugin 9.0.0 Wed Sep 9 17:22:50 2020 -0600 . I updated to warnings ng plugin 8.4.2 Fri Sep 11 16:39:52 2020 -0600. The freestyle and pipeline jobs that reported the null pointer exception had entries in their job history that were generated after the installation of analysis model api plugin 9.0.0 and before the installation of warnings ng plugin 8.4.2.

I'm not sure how I will locate all the builds that I need to delete other than by trail and error. I assume I'll need a technique like this:

• Search for the detected failing jobs in Jenkins and delete their builds that were after Wed Sep 9 17:22:50 2020 -0600
• Install warnings-ng plugin 8.4.2
• Run those jobs again and see if they now pass

Have I understood the process?

If that process is correct, then I have relatively few jobs that I need to delete, as identified by

$ grep -l -F -r 'io.jenkins.plugins.analysis.core.model.AnalysisHistory.getIssues' .
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=FreeBSD-12/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=Ubuntu-20/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=s390x/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=Ubuntu-18/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=CentOS-7/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=Debian-10/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=Debian-9/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=CentOS-8/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=windows/50/log
./builds/Git-Folder/git-plugin-multi-platform/jdk=jdk8,os=Debian-testing/50/log
./builds/Git-Folder/git-pipeline-bitbucket/master/30/log
./builds/Git-Folder/git-pipeline-bitbucket/master/30/workflow/flowNodeStore.xml
./builds/Git-Folder/git-plugin-no-coverage/31/log
./builds/Git-Folder/git-plugin-pipeline/JENKINS-37263/2/log
./builds/Git-Folder/git-plugin-pipeline/JENKINS-37263/2/workflow/flowNodeStore.xml
./builds/Git-Folder/git-plugin-pipeline/JENKINS-37263/1/log
./builds/Git-Folder/git-plugin-pipeline/JENKINS-37263/1/workflow/flowNodeStore.xml
./builds/Git-Folder/git-pipeline-github/JENKINS-37263/1/log
./builds/Git-Folder/git-pipeline-github/JENKINS-37263/1/workflow/flowNodeStore.xml
./builds/Git-Folder/git-pipeline-github/master/35/log
./builds/Git-Folder/git-pipeline-github/master/35/workflow/flowNodeStore.xml
./builds/Git-Folder/git-plugin-on-branch/14/log

That pattern match search through the Jenkins logs shows the jobs that are affected. I visited each of those jobs and removed all builds in the window of time between install of analysis-api plugin 9.0.0 and warnings-ng plugin 8.4.2. I've upgraded the warnings-ng plugin to 8.4.2 and restarted the Jenkins server. Jobs are running now.

Ah, good to see that everything is ok after you deleted those builds. The serialization for these jobs was simply empty And I see no simple way to provide a fall back for such a bug.

Root cause: JENKINS-63652

Workaround: jobs that are created with analysis-model 9.0.0 and warnings 8.4.1 need to be deleted.

I have at a few pipeline jobs where all builds of the job were deleted and it reported a null pointer exception on the new build attempted after installing warnings-ng 8.4.2. I'll continue exploring further to try to better understand the conditions.

Ok, then I reopen and check on my machine as well...

The pipeline jobs that failed after I had deleted all history were then able to pass on the next build. It may be enough to try another time after the first deletion.

I see, I have a job on my machine with the same problem as well now, so I can reproduce it and debug it...

Sorry, the job with the same problem had a broken build (serialization with model 9.0.0 and without warnings 8.4.2). It contained the XML element

<analysisReport serialization="custom">

in one of the serialized warnings XML files. Correct should be:

<analysisReport plugin="analysis-model-api@9.0.0">

Maybe you can check on disk if there is still such a file around?

I have that flawed entry in many more jobs than the cases that I detected in previous exploring.

I see that warninigs-ng 8.4.1 was installed on ci.jenkins.io two days ago. That means we have two days worth of builds on that very busy server that would need to be deleted. I've asked the infrastructure IRC to not upgrade the ci.jenkins.io warnings-ng plugin until this is better understood. I don't want to delete many, many builds on ci.jenkins.io if I can possibly avoid it.

Would it reduce the risk to ci.jenkins.io if it were rolled back to warnings-ng 8.4.0?

This has been a very helpful reminder for me that I need to scan the log files of all the jobs in my test server for null pointer exceptions. It showed that there are other cases (for example, one in the git plugin) that were reporting a null pointer exception to the log). I missed those failures because there are more jobs on the instance than I can reasonably scan as a person.

The problem actually is not caused by something in warnings 8.4.1. It is caused by an upgrade to analysis-model 9.0.0. It was easier to fix in warnings plugin, so I released 8.4.2. 

Since the issue is in analysis model 9.0.0, I assume that means there is no impact on ci.jenkins.io because it is still running analysis model 8.3.1. Is that assumption correct?

Yes, then this should not have any impact. The problem was that in analysis-model 9.0.0 I added a read/writeObject method to the report class which caused XStream to skip everything during serialization. I fixed this by creating a new mapper in warnings-ng. 

I have analysis-model 9.0.0 and warnings-ng 8.4.2 - and it does not work. Should it ?
( that is when I added the defect 63677 this morning - sorry for the duplicate )

If you delete those builds (see https://issues.jenkins-ci.org/browse/JENKINS-63659?focusedCommentId=397356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-397356) then it should work again.

Excellent - thanks. Had to delete all results after 10. September. ( everything on Friday 11th and at the weekend )
History ( 10. Sept and before ) is back again.

Ok, good to see. Sorry for the inconvenience...

I am currently running jenkins 2.249.1 and was experiencing the same NPE since updating some plugins yesterday.

After downgrading Warnings NG to 8.4.1 the failing jobs are working again.

I am not sure if this makes any sense based on the findings about the issue I read here in the comments.

Sorry but for us it is not a nice option to delete the history for hundreds of build jobs. Is it not possible to fix this somehow in an 8.4.3 version? At the moment we have reverted to 8.4.1!

Same to me with:

• Jenkins 2.256
• Analysis Model API Plugin 9.0.0
• Warnings NG 8.4.2

So I just reverted to Warnings NG 8.4.1 and everything is fine again.

Hmm, reverting to 8.4.1 helps? That is strange. The actual problem is located in Analysis Model API Plugin 9.0.0. So if you are running 8.4.1 with Analysis Model API Plugin 9.0.0 then the old results should not show up anymore (see JENKINS-63652).

Can you please check if you are running with Analysis Model API Plugin 9.0.0 and warnings 8.4.1

• in your build XML files that store the warnings, what header tag is used? It should start with <analysisReport serialization="custom">
• can you open an old report and see the issues in the table?
• can you create a new build and see the issues in the table?
• restart Jenkins and try again if you can open old and new results

Same for me. Fixed by reverting Warnings NG to 8.4.1.

Same here,

After reverting to Warnings NG 8.4.1 the NullPointer is gone.

In the first place it's important to have working jobs without an exception. An exception is a worse failure than missing results. From that point I don't understand the priority of that issue.

Yes I am currently running Analysis Model API Plugin 9.0.0 and warnings 8.4.1 but I don't know when I updated Analysis Model API Plugin. I can open Warnings NG results from the day before the warnings update.

In the xml file I see this header:

"<analysisReport serialization="custom">"

I can see issues of that build as well as issues from the latest builds with Warnings 8.4.1 in the table. I did a jenkins restart after the 8.4.1 downgrade.

Analysis Model API Plugin was updated 6 days ago - 10th September. I installed it on the 11th.
API Plugin 9.0 and Warnings NG 8.4.2 work and previous results can be seen ... but only if the builds since 11.sept and before 14th are deleted.
Hope it helps..

We have a lot of jobs using Analysis Model API Plugin and Warnings NG. Manually deleting the builds from 11.sept to 14.sept will cost half of my days work. Seems not to bee a good option in my eyes.
I'll be patient and wait until this bug is fixed before upgrading again ...

At the moment with 8.4.1 Warings Next Generation and Analysis Model API 9.0.0 the header looks like this:

<analysisReport serialization="custom">

Before the update of Analysis Model API it was:

<analysisReport plugin="analysis-model-api@8.3.1">

So it seems to me that builds in the history generated with Warnings 8.4.1 and Analysis Model 9.0.0 are not working with Warnings 8.4.2.

Can someone attach a file with the <analysisReport serialization="custom"> content? On my machine these files are just empty tags without any issues.

Ok, thanks for attaching. This is what I expected, the report is empty: there are no issues persisted! So this confirms that 8.4.1. and 9.0.0 do not fix the problem.

My file contains a lot of issues but I can't send it without a huge amount of modification..... sorry.

This is the beginning with the first issue:

<?xml version='1.1' encoding='UTF-8'?>
<analysisReport serialization="custom">
  <analysisReport>
    <int>763</int>
    <string>D:/workdir/.jenkins</string>
    <string>../build/XXX/workspace/XXX/XXX/XXX.h</string>
    <int>52</int>
    <int>52</int>
    <int>0</int>
    <int>0</int>
    <edu.hm.hafner.analysis.LineRangeList/>
    <string>C4251</string>
    <string>-</string>
    <string>-</string>
    <string></string>
    <string>NORMAL</string>
    <string>&apos;XXX::XXX; : XXX;</string>
    <string></string>
    <string>msbuild</string>
    <string>1129</string>
    <string>94E8C005B75E7F70F8B26995F31908FA</string>
    <null/>
    <uuid>cac68e48-4c64-45f4-a3ab-318967d8d728</uuid>

I think the file maven-warnings-outstanding-issues.xml in the analysisReports.zip should have issues.

So these are possible workarounds up to now:

• Install warnings-ng 8.4.2 and analysis-model 9.0.0 and delete all builds that contain files with <analysisReport serialization="custom">
• Install warnings-ng 8.4.2 and analysis-model 9.0.0 and overwrite files with <analysisReport serialization="custom"> with a file from one of your old builds (that contains <analysisReport plugin="analysis-model-api@9.0.0">)
• Revert to warnings-ng 8.4.1 and analysis-model 9.0.0

Any progress? Because i think this is NOT minor bug but critical bug. When ALL jobs failing and whole server is paralyzed it is not minor bug..

Did you try one of the workarounds?

Yes, I confirm  "Revert to warnings-ng 8.4.1 and analysis-model 9.0.0" work for me. 

I had a similar problem with later versions, but got it solved already.

I got this stack trace when using Warnings Next Generation Plugin 8.4.4 and Analysis Model API Plugin 9.2.1 on 2020-10-28, for build #69 of a branch whose previous build #68 had been done on 2020-02-03:

java.lang.NullPointerException
  at java.util.AbstractCollection.addAll(AbstractCollection.java:343)
  at edu.hm.hafner.analysis.Report.copyProperties(Report.java:669)
  at edu.hm.hafner.analysis.Report.copyIssuesAndProperties(Report.java:661)
  at edu.hm.hafner.analysis.Report.addAll(Report.java:194)
  at io.jenkins.plugins.analysis.core.model.AnalysisResult.getIssues(AnalysisResult.java:413)
  at io.jenkins.plugins.analysis.core.model.AnalysisHistory$$Lambda$359/0000000000000000.apply(Unknown Source)
  at java.util.Optional.map(Optional.java:215)
  at io.jenkins.plugins.analysis.core.model.AnalysisHistory.getIssues(AnalysisHistory.java:142)
  at io.jenkins.plugins.analysis.core.model.DeltaReport.<init>(DeltaReport.java:48)
  at io.jenkins.plugins.analysis.core.steps.IssuesPublisher.attachAction(IssuesPublisher.java:110)
  at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.publishResult(IssuesRecorder.java:721)
  at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.record(IssuesRecorder.java:651)
  at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.perform(IssuesRecorder.java:617)
  at io.jenkins.plugins.analysis.core.steps.RecordIssuesStep$Execution.run(RecordIssuesStep.java:1024)
  at io.jenkins.plugins.analysis.core.steps.RecordIssuesStep$Execution.run(RecordIssuesStep.java:985)
  at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
  at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$$Lambda$330/0000000000000000.run(Unknown Source)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:821)

A commit on the branch soon triggered build #70, which failed with the same stack trace.

I then downgraded Warnings Next Generation Plugin from 8.4.4 to 8.4.3 and Analysis Model API Plugin from 9.2.1 to 9.1.0, and started build #71, which succeeded.

Finally, I upgraded Warnings Next Generation Plugin from 8.4.3 to 8.4.4 and Analysis Model API Plugin from 9.1.0 to 9.2.1, and started build #72, which succeeded, even though build #70 of the same commit had failed with the same plugin versions.

So, the problem apparently still exists in the newer plugin versions in some way, but I got the branch building again, without having to delete any previous builds or edit XML files.

kon Can you please file a new bug report for analysis-model? This is a different bug (though a similar exception). It needs to be fixed in analysis-model module.

drulli OK, filed as JENKINS-64070.