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

NullPointerException at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:432)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • maven-plugin
    • None
    • Hudson 1.351, Maven 2.2.1

      I've got this exception while running the build:

      ERROR: Processing failed due to a bug in the code. Please report this to users@hudson.dev.java.net
      java.lang.NullPointerException
      at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:432)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
      at hudson.model.Run.run(Run.java:1240)
      at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:304)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:122)

      This seems to be similar to http://markmail.org/message/ni72qrruszvzp63m
      However, I'm on Hudson 1.351, so the bug should have been fixed in it, right?

      I've also a Maven job with incremental build option.
      The module with the changes had already been build before. The 3 builds before this failing build, however, were aborted manually.

      Deactivating the incremental build option and starting the build manually helped.

          [JENKINS-6429] NullPointerException at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:432)

          I'm having a similar problem with Hudson 1.356
          java.lang.NullPointerException
          at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:435)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
          at hudson.model.Run.run(Run.java:1244)
          at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:306)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:122)

          Vincent Latombe added a comment - I'm having a similar problem with Hudson 1.356 java.lang.NullPointerException at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:435) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1244) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:306) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122)

          I just runned the incriminating job once again, and it seems to be due to a duplicated module.

          Vincent Latombe added a comment - I just runned the incriminating job once again, and it seems to be due to a duplicated module.

          kutzi added a comment -

          As far as I can reconstruct it, no duplicate module has been involved in my case.

          kutzi added a comment - As far as I can reconstruct it, no duplicate module has been involved in my case.

          Andrew Bayer added a comment -

          I'm not sure if I'm going to have time to look into this for a while due to work - check with Kohsuke to see if he can take a look.

          Andrew Bayer added a comment - I'm not sure if I'm going to have time to look into this for a while due to work - check with Kohsuke to see if he can take a look.

          kutzi added a comment -

          Strange. I did a view on the source code and it looks to me pretty much impossible that a NPE is happening there.

          The line 432 resp. 435 is
          if ((mb.getPreviousBuiltBuild() == null) ||

          while mb is instantiated some lines earlier with
          MavenBuild mb = m.newBuild();

          And it looks like newBuild() can never return null

          kutzi added a comment - Strange. I did a view on the source code and it looks to me pretty much impossible that a NPE is happening there. The line 432 resp. 435 is if ((mb.getPreviousBuiltBuild() == null) || while mb is instantiated some lines earlier with MavenBuild mb = m.newBuild(); And it looks like newBuild() can never return null

          kutzi added a comment -

          I just had the exact same problem again. Again, the previous build was aborted manually, so that seems to be the cause (there were no aborted builds in the mean time).
          Starting the full build by manually triggering the job, fixed it again.

          kutzi added a comment - I just had the exact same problem again. Again, the previous build was aborted manually, so that seems to be the cause (there were no aborted builds in the mean time). Starting the full build by manually triggering the job, fixed it again.

          kutzi added a comment -

          I think this could be the offending line:

          (mb.getPreviousBuiltBuild().getResult().isWorseThan(Result.SUCCESS)))

          I've seen before that a build Result could be null for aborted builds - maybe the best way is to make sure that getResult() will never return null as it is quite intuitive to assume that getResult() (at least for a past job) will never return null.

          Still wonder why the reported line number in the stacktrace is incorrect.

          kutzi added a comment - I think this could be the offending line: (mb.getPreviousBuiltBuild().getResult().isWorseThan(Result.SUCCESS))) I've seen before that a build Result could be null for aborted builds - maybe the best way is to make sure that getResult() will never return null as it is quite intuitive to assume that getResult() (at least for a past job) will never return null. Still wonder why the reported line number in the stacktrace is incorrect.

          Andrew Bayer added a comment -

          Theoretically, getResult() should never return null, but yeah, I wouldn't be shocked if it still does in some weird cases.

          Andrew Bayer added a comment - Theoretically, getResult() should never return null, but yeah, I wouldn't be shocked if it still does in some weird cases.

          kutzi added a comment -

          The constructor
          protected Run(JobT job, long timestamp)

          doesn't set the result initially, so maybe that's the cause?

          kutzi added a comment - The constructor protected Run(JobT job, long timestamp) doesn't set the result initially, so maybe that's the cause?

          drhudgins added a comment -

          This was a sore spot for me as well until I put a try/catch(RuntimeException e) around the
          if (mb.getPreviousBuiltBuild().getResult().isWorseThan(Result.SUCCESS))

          drhudgins added a comment - This was a sore spot for me as well until I put a try/catch(RuntimeException e) around the if (mb.getPreviousBuiltBuild().getResult().isWorseThan(Result.SUCCESS))

          Andrew Bayer added a comment -

          For the incremental build logic, if getResult() is null, what do you think the behavior should be? The easiest approach would be to add a check for mb.getPreviousBuiltBuild().getResult()==null ahead of the isWorseThan check in that if statement - so that if the previous build result for the module we're checking is null, we assume it needs to be built this time. This will result in some superfluous builds, but the only alternative I can think of is to check earlier builds, which would be ugly and error-prone.

          Andrew Bayer added a comment - For the incremental build logic, if getResult() is null, what do you think the behavior should be? The easiest approach would be to add a check for mb.getPreviousBuiltBuild().getResult()==null ahead of the isWorseThan check in that if statement - so that if the previous build result for the module we're checking is null, we assume it needs to be built this time. This will result in some superfluous builds, but the only alternative I can think of is to check earlier builds, which would be ugly and error-prone.

          kutzi added a comment -

          I don't see what is so ugly about checking earlier builds but for me just assuming that the module needs to be build is IMO good enough in this case, as aborting builds should be the exception.

          kutzi added a comment - I don't see what is so ugly about checking earlier builds but for me just assuming that the module needs to be build is IMO good enough in this case, as aborting builds should be the exception.

          kutzi added a comment -

          Actually, I think that Run#getPreviousBuiltBuild should already skip builds with a null result.
          At least it does fit to what that method is supposed to return IMHO.

          And even better would be to make sure that Run#getResult will never ever return null (at least when the build is not running anymore). I've been bitten by a null result while developing a plugin already, too.

          Of course, this is a much bigger change than just checking for null in MavenModuleSetBuild.

          kutzi added a comment - Actually, I think that Run#getPreviousBuiltBuild should already skip builds with a null result. At least it does fit to what that method is supposed to return IMHO. And even better would be to make sure that Run#getResult will never ever return null (at least when the build is not running anymore). I've been bitten by a null result while developing a plugin already, too. Of course, this is a much bigger change than just checking for null in MavenModuleSetBuild.

          kutzi added a comment -

          Can we at least get the 'easy' solution - check if Result is null and assume module has to be build in that case - quickly?

          Anything is better than the current NPE.

          kutzi added a comment - Can we at least get the 'easy' solution - check if Result is null and assume module has to be build in that case - quickly? Anything is better than the current NPE.

          kutzi added a comment -

          Is there anything happening regarding this issue?
          If not, I could try to create a patch for this on myself and attach it here for review.

          kutzi added a comment - Is there anything happening regarding this issue? If not, I could try to create a patch for this on myself and attach it here for review.

          chomats added a comment -

          I had this problem : I renamed a module (change case only) and the next job failed.

          chomats added a comment - I had this problem : I renamed a module (change case only) and the next job failed.

          chomats added a comment -

          I restarted a new job and it's ok.

          chomats added a comment - I restarted a new job and it's ok.

          kutzi added a comment -

          Just to note the severity of this issue for my organisation:
          It happens EVERY time when a build was aborted and the next one is started incrementally!

          kutzi added a comment - Just to note the severity of this issue for my organisation: It happens EVERY time when a build was aborted and the next one is started incrementally!

          kutzi added a comment -

          This is a patch which should fix the issue.
          Could someone please review it and apply it, if possible?

          kutzi added a comment - This is a patch which should fix the issue. Could someone please review it and apply it, if possible?

          Andrew Bayer added a comment -

          Ooooo, that makes sense. I'll review/apply this today.

          Andrew Bayer added a comment - Ooooo, that makes sense. I'll review/apply this today.

          Code changed in hudson
          User: : abayer
          Path:
          trunk/hudson/main/core/src/main/java/hudson/model/Run.java
          http://jenkins-ci.org/commit/33250
          Log:
          [FIXED JENKINS-6429] Check for null results to handle aborted incremental Maven builds - thanks to kutzi for the patch

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/hudson/main/core/src/main/java/hudson/model/Run.java http://jenkins-ci.org/commit/33250 Log: [FIXED JENKINS-6429] Check for null results to handle aborted incremental Maven builds - thanks to kutzi for the patch

          Code changed in hudson
          User: : abayer
          Path:
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/33251
          Log:
          [FIXED JENKINS-6429] Check for null results to handle aborted incremental Maven builds - thanks to kutzi for the patch

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/www/changelog.html http://jenkins-ci.org/commit/33251 Log: [FIXED JENKINS-6429] Check for null results to handle aborted incremental Maven builds - thanks to kutzi for the patch

            abayer Andrew Bayer
            kutzi kutzi
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: