java.lang.NullPointerException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • For some of our components, Jenkins build fails with the following error message in the console log: {noformat} Preparing to execute si projectinfo for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj Preparing to execute pre-build si checkpoint for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj Successfully executed pre-build checkpoint for project #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj, new revision is 1.115 Preparing to execute si viewproject for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.115 Checkout directory is /jenkins/mks/dev_Rel7.8/ComponentA/ModuleA A clean copy is requested; deleting contents of /jenkins/mks/dev_Rel7.8/ComponentA/ModuleA Populating clean workspace... FATAL: null java.lang.NullPointerException at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:277) at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:24) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.IntegritySCM.checkout(IntegritySCM.java:790) at hudson.model.AbstractProject.checkout(AbstractProject.java:1415) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) {noformat} The build fails under those circumstances: - The affected integrity project is a variant (development path) project. - The original project of that variant project has been moved. In this case, the module {{d:/MKS/PlatformA/OldComponent/ModuleA}} (MKS project name: {{d:/MKS/PlatformA/OldComponent/ModuleA/ModuleA.pj}}) has been moved to {{d:/MKS/PlatformA/ComponentA/ModuleA}} (new MKS project name: {{d:/MKS/PlatformA/ComponentA/ModuleA/project.pj}}) *Problem analysis:* The code line at {noformat} hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:277) {noformat} accesses the configuration path of a member in a prepared member list structure, which is null: {noformat} String configPath = memberInfo.get(CM_PROJECT.CONFIG_PATH).toString(); {noformat} The main cause seems to be speciality in integrity with the {{si projectinfo}} (this is the way currently implemented in the integrity plugin): {noformat} si projectinfo --project="d:/MKS/PlatformA/ComponentA/ModuleA/project.pj" --projectRevision="1.116" {noformat} Result: {noformat} Build Project Name: d:/MKS/PlatformA/OldComponent/ModuleA/ModuleA.pj Server: ... Configuration Path: #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.116 ... {noformat} Here we get back the old project name (which was valid before the move). But when we execute project info using the configuration path we get the new project name as a result: {noformat} si projectinfo --project="#p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114" {noformat} Result: {noformat} Build Project Name: d:/MKS/PlatformA/ComponentA/ModuleA/project.pj Server: ... Configuration Path: #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114 Revision: 1.114 ... {noformat} The problem is that during {{IntegrityCMProject.parseProject()}}, where the project including it's members is parsed, the project name that comes with the member infos is matched against that name ({{using Hashtable<String, String> pjConfigHash}}) to find out the configuration path for each member. Here the "new name" is matched against the "old name" so that the config path stays null. My proposal for a workaround would be to change the implementation to the second way in {{IntegritySCM.checkout()}}: {noformat} Command siProjectInfoCmd = new Command(Command.SI, "projectinfo"); //instead of //siProjectInfoCmd.addOption(new Option("project", siProject.getProjectName())); //siProjectInfoCmd.addOption(new Option("projectRevision", chkpt)); //we would use siProjectInfoCmd.addOption(new Option("project", siProject.getConfigurationPath() + "#forceJump=#b=" + chkpt)); Response infoRes = api.runCommand(siProjectInfoCmd); {noformat} We have this approach in use for our projects and it solves that problem. It would be nice if we could have the fix/workaround in one of the next ptc-integrity plugin revisions. I will provide a pull request with that solution.
    via by Christian Bürenheide,
  • For some of our components, Jenkins build fails with the following error message in the console log: {noformat} Preparing to execute si projectinfo for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj Preparing to execute pre-build si checkpoint for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj Successfully executed pre-build checkpoint for project #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj, new revision is 1.115 Preparing to execute si viewproject for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.115 Checkout directory is /jenkins/mks/dev_Rel7.8/ComponentA/ModuleA A clean copy is requested; deleting contents of /jenkins/mks/dev_Rel7.8/ComponentA/ModuleA Populating clean workspace... FATAL: null java.lang.NullPointerException at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:277) at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:24) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.IntegritySCM.checkout(IntegritySCM.java:790) at hudson.model.AbstractProject.checkout(AbstractProject.java:1415) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) {noformat} The build fails under those circumstances: - The affected integrity project is a variant (development path) project. - The original project of that variant project has been moved. In this case, the module {{d:/MKS/PlatformA/OldComponent/ModuleA}} (MKS project name: {{d:/MKS/PlatformA/OldComponent/ModuleA/ModuleA.pj}}) has been moved to {{d:/MKS/PlatformA/ComponentA/ModuleA}} (new MKS project name: {{d:/MKS/PlatformA/ComponentA/ModuleA/project.pj}}) *Problem analysis:* The code line at {noformat} hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:277) {noformat} accesses the configuration path of a member in a prepared member list structure, which is null: {noformat} String configPath = memberInfo.get(CM_PROJECT.CONFIG_PATH).toString(); {noformat} The main cause seems to be speciality in integrity with the {{si projectinfo}} (this is the way currently implemented in the integrity plugin): {noformat} si projectinfo --project="d:/MKS/PlatformA/ComponentA/ModuleA/project.pj" --projectRevision="1.116" {noformat} Result: {noformat} Build Project Name: d:/MKS/PlatformA/OldComponent/ModuleA/ModuleA.pj Server: ... Configuration Path: #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.116 ... {noformat} Here we get back the old project name (which was valid before the move). But when we execute project info using the configuration path we get the new project name as a result: {noformat} si projectinfo --project="#p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114" {noformat} Result: {noformat} Build Project Name: d:/MKS/PlatformA/ComponentA/ModuleA/project.pj Server: ... Configuration Path: #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114 Revision: 1.114 ... {noformat} The problem is that during {{IntegrityCMProject.parseProject()}}, where the project including it's members is parsed, the project name that comes with the member infos is matched against that name ({{using Hashtable<String, String> pjConfigHash}}) to find out the configuration path for each member. Here the "new name" is matched against the "old name" so that the config path stays null. My proposal for a workaround would be to change the implementation to the second way in {{IntegritySCM.checkout()}}: {noformat} Command siProjectInfoCmd = new Command(Command.SI, "projectinfo"); //instead of //siProjectInfoCmd.addOption(new Option("project", siProject.getProjectName())); //siProjectInfoCmd.addOption(new Option("projectRevision", chkpt)); //we would use siProjectInfoCmd.addOption(new Option("project", siProject.getConfigurationPath() + "#forceJump=#b=" + chkpt)); Response infoRes = api.runCommand(siProjectInfoCmd); {noformat} We have this approach in use for our projects and it solves that problem. It would be nice if we could have the fix/workaround in one of the next ptc-integrity plugin revisions. I will provide a pull request with that solution.
    via by Christian Bürenheide,
    • java.lang.NullPointerException at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:894) at hudson.model.AbstractBuild.access$600(AbstractBuild.java:104) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:634) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1745) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240)
    No Bugmate found.