• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Critical Critical
    • core
    • None
    • Linux Suse, Tomcat 7.0.27, JDK 1.6.0_29

      After upgrading Jenkins to 1.599 all executors start dying because of the error below. All my jobs are configured to discard old builds.

      java.lang.IllegalStateException: cannot create a build with number 1447 since that (or higher) is already in use among [1415, 1416, 1417, 1418, 1419, 1420, 1421, 1422, 1423, 5288]
      at jenkins.model.lazy.AbstractLazyLoadRunMap.proposeNewNumber(AbstractLazyLoadRunMap.java:361)
      at hudson.model.RunMap.put(RunMap.java:189)
      at jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:178)
      at hudson.model.AbstractProject.newBuild(AbstractProject.java:1006)
      at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1205)
      at hudson.model.AbstractProject.createExecutable(AbstractProject.java:144)
      at hudson.model.Executor.run(Executor.java:213)

      I could see that the method SortedIntList.isInRange does not check the list content. So I changed it to the code below and everything worked fine.

      public boolean isInRange(int idx)

      { return find(idx)>-1; }

      I will make a pull request with this solution.

          [JENKINS-27081] Executors are dying after upgrading to 1.599

          Bruno Carneiro added a comment - I just made a pull request: https://github.com/jenkinsci/jenkins/pull/1582

          James Nord added a comment -

          isn't this existing behavior correct - build #5288 exists and you shouldn't be able to create a buildnumber with a lower value.

          James Nord added a comment - isn't this existing behavior correct - build #5288 exists and you shouldn't be able to create a buildnumber with a lower value.

          In some way I agree with you.
          What I found out is one module of my project (.jenkins/jobs/job_name/modules/module_name) was with 'nextBuildNumber' (#5288) different than the others modules.
          However, in my opinion, Jenkins should be more resilient when dealing with jobsNumbers. #1447 is a valid next job number, but #5288 isn't.

          Bruno Carneiro added a comment - In some way I agree with you. What I found out is one module of my project (.jenkins/jobs/job_name/modules/module_name) was with 'nextBuildNumber' (#5288) different than the others modules. However, in my opinion, Jenkins should be more resilient when dealing with jobsNumbers. #1447 is a valid next job number, but #5288 isn't.

          James Nord added a comment -

          1447 is NOT a valid next build number as it is < 5288.
          For the number to be valid it must be > 5288.

          Is this using the Maven2 type job?

          The fix is to move nextBuildNumber past 5288 which can be done by shutting down jenkins and editing the nextBuildNumber in the job and modules directory in jenkins such that the number is > 5288.

          Then what remains is to work out how this state came about and prevent it.

          James Nord added a comment - 1447 is NOT a valid next build number as it is < 5288. For the number to be valid it must be > 5288. Is this using the Maven2 type job? The fix is to move nextBuildNumber past 5288 which can be done by shutting down jenkins and editing the nextBuildNumber in the job and modules directory in jenkins such that the number is > 5288. Then what remains is to work out how this state came about and prevent it.

          Yes, it's a Maven2 type job.
          When I fixed the nextBuildNumber it worked correctly.

          Bruno Carneiro added a comment - Yes, it's a Maven2 type job. When I fixed the nextBuildNumber it worked correctly.

            Unassigned Unassigned
            brunocarneiro Bruno Carneiro
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: