• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • None
    • Microsoft Windows Server 2003 R2
      Microsoft Windows 2008 server w/Tomcat
      Microsoft Windows XP SP3
      Microsoft Windows 7 x64 SP1
      Microsoft Windows Server 2012

      When I try to start Jenkins 1.540, it attempts to do so and eventually fails. When it fails, it tries to start again, which then fails. This repeats indefinitely. I've attached a log file from one such iteration.

      I am able to start 1.539 successfully. I've attached the log file from this as well.

        1. hs_err_pid1000.log
          17 kB
        2. hs_err_pid1788.log
          22 kB
        3. hs_err_pid35184.log
          24 kB
        4. hs_err_pid4584.log
          13 kB
        5. hs_err_pid4968.log
          20 kB
        6. hs_err_pid5660.log
          21 kB
        7. hs_err_pid5960.log
          21 kB
        8. jenkins.out.log
          0.8 kB
        9. jenkins 1.539.err.log
          40 kB
        10. jenkins 1.540.err.log
          27 kB

          [JENKINS-20630] Jenkins fails to start

          Adam Ocsvari added a comment -

          The same here:
          Windows7 x64, running Jenkins as a service. Before the update to 1.540, it was working fine.

          Adam Ocsvari added a comment - The same here: Windows7 x64, running Jenkins as a service. Before the update to 1.540, it was working fine.

          Andy Bigos added a comment - - edited

          +1. Running Win7 x64 as a service and got the same errors. Reverting to 1.539 works.

          Andy Bigos added a comment - - edited +1. Running Win7 x64 as a service and got the same errors. Reverting to 1.539 works.

          Confirmed: There is something wrong with 1.540 that causes the JVM it to crash on Windows just after startup.

          I have a very similar issue. Windows 8, java 7_45, downloaded the latest Windows install of Jenkins version 1.540. Ran the the msi install and ran this command as administrator:

          C:\Program Files (x86)\Jenkins>java -jar jenkins.war

          When it got to "INFO: Loaded all jobs" in the command console log output the JVM crashed and popped up a Java Virtual Machine has unexpected shut down dialog message.

          After a few more ties with no success I downloaded the previous build 1.539 war file from

          http://mirrors.jenkins-ci.org/war/1.539/

          Overwrote C:\Program Files (x86)\Jenkins>jenkins.war

          Ran this again

          C:\Program Files (x86)\Jenkins>java -jar jenkins.war

          and Jenkins started normally.

          Jonathan Johnson added a comment - Confirmed: There is something wrong with 1.540 that causes the JVM it to crash on Windows just after startup. I have a very similar issue. Windows 8, java 7_45, downloaded the latest Windows install of Jenkins version 1.540. Ran the the msi install and ran this command as administrator: C:\Program Files (x86)\Jenkins>java -jar jenkins.war When it got to "INFO: Loaded all jobs" in the command console log output the JVM crashed and popped up a Java Virtual Machine has unexpected shut down dialog message. After a few more ties with no success I downloaded the previous build 1.539 war file from http://mirrors.jenkins-ci.org/war/1.539/ Overwrote C:\Program Files (x86)\Jenkins>jenkins.war Ran this again C:\Program Files (x86)\Jenkins>java -jar jenkins.war and Jenkins started normally.

          Having the same issue running Jenkins 1.540 on Tomcat 7.0.47 on Windows Server 2008 R2 Standard. Tomcat is running as a Windows Service. Once I downgraded to 1.539 it starts up perfectly.

          Brandon Oakley added a comment - Having the same issue running Jenkins 1.540 on Tomcat 7.0.47 on Windows Server 2008 R2 Standard. Tomcat is running as a Windows Service. Once I downgraded to 1.539 it starts up perfectly.

          Fails to start:

            • Windows 2008 server running Apache Tomcat 7
              Apache Tomcat 7 crashes

          Gemini Agaloos added a comment - Fails to start: Windows 2008 server running Apache Tomcat 7 Apache Tomcat 7 crashes

          Akira Yamamoto added a comment - - edited

          Same here: Windows Server 2008 R2 x64, running Jenkins as a service. Before the update to 1.540, it was working fine.

          java version "1.7.0_45"
          Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
          Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

          There is a file jenkins.war.bak you can use it to restore to previous version.

          Akira Yamamoto added a comment - - edited Same here: Windows Server 2008 R2 x64, running Jenkins as a service. Before the update to 1.540, it was working fine. java version "1.7.0_45" Java(TM) SE Runtime Environment (build 1.7.0_45-b18) Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) There is a file jenkins.war.bak you can use it to restore to previous version.

          Joseph S added a comment - - edited

          Same here, new Windows 2012 box, just to run Jenkins, Java crashes.

          As said before, latest 1.540 doesn't work. Rolled back to 1.539 and works just fine.

          Windows Server 2012 Standard Build 9200

          Joseph S added a comment - - edited Same here, new Windows 2012 box, just to run Jenkins, Java crashes. As said before, latest 1.540 doesn't work. Rolled back to 1.539 and works just fine. Windows Server 2012 Standard Build 9200

          Build Team added a comment -

          jenkins.out.logs shows

          1. Problematic frame:
          2. C [ntdll.dll+0x2df85]

          Build Team added a comment - jenkins.out.logs shows Problematic frame: C [ntdll.dll+0x2df85]

          Build Team added a comment - - edited

          Having a similar issue with 1.540 in Standalone mode i.e. Jenkins service fails to start. The log "jenkins.out.log" shows this

          1. Problematic frame:
          2. C [ntdll.dll+0x2df85]

          Windows Server 2008 Standard R2 x64 Service Pack 1

          Build Team added a comment - - edited Having a similar issue with 1.540 in Standalone mode i.e. Jenkins service fails to start. The log "jenkins.out.log" shows this Problematic frame: C [ntdll.dll+0x2df85] Windows Server 2008 Standard R2 x64 Service Pack 1

          Luiko Czub added a comment -

          The same here: WinXP SP3, 1.7.0_45, jenkins standalone

          • after switching back to 1.539 jenkins starts works fine again

          Luiko Czub added a comment - The same here: WinXP SP3, 1.7.0_45, jenkins standalone after switching back to 1.539 jenkins starts works fine again

          Having same issue here ..this is my first day with jenkin almost lost whole day with jenkin setup and now this ..Annoying

          Jagannath Behera added a comment - Having same issue here ..this is my first day with jenkin almost lost whole day with jenkin setup and now this ..Annoying

          Linards L added a comment -

          Same here after upgrade from v1.529.

          Linards L added a comment - Same here after upgrade from v1.529.

          Kerem Kat added a comment -

          +1

          Kerem Kat added a comment - +1

          Shannon Kerr added a comment -

          jagannath behera, you should never use a nightly build when you are just trying out a new software. Jenkins has LTS releases that are solid and should be used if you are just starting out. Also, I typically wait a day or two before moving to the latest nightly build to see what the community ratings are and if any major bugs are reported in the tracker. 1.539 has excellent ratings if you still want to use a nightly, bleeding edge, build.

          Shannon Kerr added a comment - jagannath behera, you should never use a nightly build when you are just trying out a new software. Jenkins has LTS releases that are solid and should be used if you are just starting out. Also, I typically wait a day or two before moving to the latest nightly build to see what the community ratings are and if any major bugs are reported in the tracker. 1.539 has excellent ratings if you still want to use a nightly, bleeding edge, build.

          i'm having the same problem, java crashes shortly after loading jenkins. rolling back fixes the problem. any idea when a fix will be available. i updated some of my plugins that now will not run because they need the newer jenkins.

          william schilp added a comment - i'm having the same problem, java crashes shortly after loading jenkins. rolling back fixes the problem. any idea when a fix will be available. i updated some of my plugins that now will not run because they need the newer jenkins.

          Shannon - Any typical consumer who lands on the main http://jenkins-ci.org/ page (typically via a search engine) will see on the right hand side "Latest and greatest" and all the various platform installers, all linking to build 1540. The information about downloading does not say untested, unstable, bleeding edge build it specifically states "and greatest". Most people would assume not to have to always go to the previous build or hunt user ratings. The Jenkins site should not put the onus on the hundreds+ consumers and instead the build should be pushed to the main site only when enough time has gone by or the users rating rise above some threshold. At minimum the site should remove the subjective marketing text "and greatest" since latest builds are not backed by data from user ratings and test validations.

          Jonathan Johnson added a comment - Shannon - Any typical consumer who lands on the main http://jenkins-ci.org/ page (typically via a search engine) will see on the right hand side "Latest and greatest" and all the various platform installers, all linking to build 1540. The information about downloading does not say untested, unstable, bleeding edge build it specifically states "and greatest". Most people would assume not to have to always go to the previous build or hunt user ratings. The Jenkins site should not put the onus on the hundreds+ consumers and instead the build should be pushed to the main site only when enough time has gone by or the users rating rise above some threshold. At minimum the site should remove the subjective marketing text "and greatest" since latest builds are not backed by data from user ratings and test validations.

          i strongly agree with Jonathan. in addition, the only reason i upgraded my installation of jenkins was due to a message on the jenkins control page that indicated a new version of jenkins was available. i thought (apparently incorrectly) that the jenkins control panel would only tell me that a new version was available if that version was a stable release. if that is not the case, then the message should say:

          New (possible unstable) version of Jenkins (x.x.x) is available for download. NOTE: use at your own risk.

          william schilp added a comment - i strongly agree with Jonathan. in addition, the only reason i upgraded my installation of jenkins was due to a message on the jenkins control page that indicated a new version of jenkins was available. i thought (apparently incorrectly) that the jenkins control panel would only tell me that a new version was available if that version was a stable release. if that is not the case, then the message should say: New (possible unstable) version of Jenkins (x.x.x) is available for download. NOTE: use at your own risk.

          Shannon Kerr added a comment -

          Jonathan - Sure, I agree with you that there is no text on the site that explicitly states that there is danger in using the latest and greatest. I assumed as much when I first came to the site. The "Long-Term Support Release" does say "Older but stable" implying potential instability with the weekly Latest and Greatest. Also, this follows along with other projects that release stable LTS builds, while allowing those that want to, to run with the bleeding edge updates.

          Perhaps it's my months of experience using the weekly builds that I was also basing my comments on. I started out using the LTS and later moved to weekly builds for my sandbox instance. I've been burned multiple times and now assume that weekly builds are never guaranteed to work. I think it is a reasonable expectation that users will check Community ratings if they exist. A more visible warning would be a good idea.

          Shannon Kerr added a comment - Jonathan - Sure, I agree with you that there is no text on the site that explicitly states that there is danger in using the latest and greatest. I assumed as much when I first came to the site. The "Long-Term Support Release" does say "Older but stable" implying potential instability with the weekly Latest and Greatest. Also, this follows along with other projects that release stable LTS builds, while allowing those that want to, to run with the bleeding edge updates. Perhaps it's my months of experience using the weekly builds that I was also basing my comments on. I started out using the LTS and later moved to weekly builds for my sandbox instance. I've been burned multiple times and now assume that weekly builds are never guaranteed to work. I think it is a reasonable expectation that users will check Community ratings if they exist. A more visible warning would be a good idea.

          @Jonathan, I concur with you too.

          @William, yes I did the same as you. All current older Jenkins installation prompts admins looking at their "Manage Jenkins" page to upgrade to the latest 1.540 build. The message is highlighted at the top of the manage Jenkins page and clearly says: "New version of Jenkins (1.540) is available for download". It also draws your attention to it via a highlighted exclamation mark. There is no mention that this may be an unstable build.

          Also, if this is indeed something that people should not use "when you are just trying out a new software"... then imho there should be an explicit statement regarding this especially when it is the one being touted as the "Latest and Greatest" right in your face on the front-page of http://jenkins-ci.org and in the main *Release* tab.

          The fact that it says "Release" and not a development, nightly build, or even release candidate or beta software makes this, from my perspective, look like an official Release version. Most people won't even notice the "Long Term Support Release" tab. Just my two cents.

          Gemini Agaloos added a comment - @Jonathan, I concur with you too. @William, yes I did the same as you. All current older Jenkins installation prompts admins looking at their "Manage Jenkins" page to upgrade to the latest 1.540 build. The message is highlighted at the top of the manage Jenkins page and clearly says: "New version of Jenkins (1.540) is available for download". It also draws your attention to it via a highlighted exclamation mark. There is no mention that this may be an unstable build. Also, if this is indeed something that people should not use "when you are just trying out a new software"... then imho there should be an explicit statement regarding this especially when it is the one being touted as the "Latest and Greatest" right in your face on the front-page of http://jenkins-ci.org and in the main * Release * tab. The fact that it says "Release" and not a development, nightly build, or even release candidate or beta software makes this, from my perspective, look like an official Release version. Most people won't even notice the "Long Term Support Release" tab. Just my two cents.

          loyal parsons added a comment -

          I have to wholeheartedly agree about both the website download linking and especially the prompting on the Manage Jenkins page.

          Perhaps these should both be submitted as issues?

          loyal parsons added a comment - I have to wholeheartedly agree about both the website download linking and especially the prompting on the Manage Jenkins page. Perhaps these should both be submitted as issues?

          Jim Goodspeed added a comment -

          Getting same issue after upgrading to 1.540 and Java 1.6.0_26

          Jim Goodspeed added a comment - Getting same issue after upgrading to 1.540 and Java 1.6.0_26

          @Shannon, as you mentioned, your experience using "weekly builds" may have made you wary of using them. My experience on the other hand is slightly different in that the company I'm currently a part of does an agile weekly production release cycle of their cloud-based Software as a Service product. As a DevOps and Release Engineer, I am part of that process and we make sure to the extent possible that our weekly releases are stable. We have large companies using/hosted on our platform and our releases need to happen live without causing any noticeable downtime to our clients. So I am skewed towards the other end of the spectrum whereby I would generally trust a weekly release unless, as you mentioned, there is a "more visible warning". Nevertheless, I agree with you that if you want a stable and tested environment, go with the LTS release. I also agree with you that in general, the latest and greatest are not always the greatest. In fact, they'd probably be buggy and crash =)

          Gemini Agaloos added a comment - @Shannon, as you mentioned, your experience using "weekly builds" may have made you wary of using them. My experience on the other hand is slightly different in that the company I'm currently a part of does an agile weekly production release cycle of their cloud-based Software as a Service product. As a DevOps and Release Engineer, I am part of that process and we make sure to the extent possible that our weekly releases are stable. We have large companies using/hosted on our platform and our releases need to happen live without causing any noticeable downtime to our clients. So I am skewed towards the other end of the spectrum whereby I would generally trust a weekly release unless, as you mentioned, there is a "more visible warning". Nevertheless, I agree with you that if you want a stable and tested environment, go with the LTS release. I also agree with you that in general, the latest and greatest are not always the greatest. In fact, they'd probably be buggy and crash =)

          Leo Leung added a comment - - edited

          I have the same problem.
          Upgrading from 1.539 to 1.540 fails to start on Windows 2008 R2, tried multiple times.
          Could not find any error messages in the logs.

          Had to roll back to 1.539.

          Leo Leung added a comment - - edited I have the same problem. Upgrading from 1.539 to 1.540 fails to start on Windows 2008 R2, tried multiple times. Could not find any error messages in the logs. Had to roll back to 1.539.

          heinzepreller added a comment -

          Same problem here,

          update from 1.538 to 1.540 fails on Windows x64 Server with tomcat as service.

          Service starts over and over again.

          heinzepreller added a comment - Same problem here, update from 1.538 to 1.540 fails on Windows x64 Server with tomcat as service. Service starts over and over again.

          Shannon Kerr added a comment - - edited

          @Gemini just to clarify, by "weekly builds" I was referring to the weekly Jenkins "Latest and Greatest" release in case some people didn't catch that. My only point was that, because my experience using the weekly Jenkins releases have sometimes been more hit than miss, I rely on the user evals before ever taking a weekly and if I wanted something stable, I would take the "Long-Term Support Release" that say they are "Older but stable" Jenkins releases. I don't disagree that if the Jenkins weekly builds are going to have stability issues as significant as 1.540 that a more explicit warning on the download page or changelog is warranted. I don't need it myself as I already understand that instability is very likely and the "Older but stable" remark on the LTS download page made it clear to me that that is where the stability is.

          Shannon Kerr added a comment - - edited @Gemini just to clarify, by "weekly builds" I was referring to the weekly Jenkins "Latest and Greatest" release in case some people didn't catch that. My only point was that, because my experience using the weekly Jenkins releases have sometimes been more hit than miss, I rely on the user evals before ever taking a weekly and if I wanted something stable, I would take the "Long-Term Support Release" that say they are "Older but stable" Jenkins releases. I don't disagree that if the Jenkins weekly builds are going to have stability issues as significant as 1.540 that a more explicit warning on the download page or changelog is warranted. I don't need it myself as I already understand that instability is very likely and the "Older but stable" remark on the LTS download page made it clear to me that that is where the stability is.

          Same to me after upgrade from 1.539 to 1.540 on Windows7 x64

          I started the update by using the jenkins->configure system->automatically update feature on our runing instance.

          First time in several years the upgraded release is broken ...

          I now reverted back to 1.539

          I'd like to provide a wish list concerning this bug:

          1. fix the bug
          2. home page
            • link stable releases and label it as stable
            • link weekly builds and label them clearly as at your own risk
          3. jenkins->configure system->update
            • link stable release only

          Norbert Pfistner added a comment - Same to me after upgrade from 1.539 to 1.540 on Windows7 x64 I started the update by using the jenkins->configure system->automatically update feature on our runing instance. First time in several years the upgraded release is broken ... I now reverted back to 1.539 I'd like to provide a wish list concerning this bug: fix the bug home page link stable releases and label it as stable link weekly builds and label them clearly as at your own risk jenkins->configure system->update link stable release only

          boris ivan added a comment -

          I think this is simple:

          1) This release should be pulled.

          2) Some kind of automated test (if only there was some kind of software package that could run integration tests after a software build, on a continuous basis) should be in place to load the nightly builds on each major OS and if they fail, then take action (back out submit, flag for review and don't release to public, any number of potential actions here)

          3) Regarding a warning on the front page.. I disagree. Not because I feel that the people suggesting this are wrong, but it promotes bad behavior/poor code. The Jenkins community responsible for the stability of the product should take steps to reduce the possibility of a bugs like this making it to release-phase, instead of saying "meh, these things happen!".

          boris ivan added a comment - I think this is simple: 1) This release should be pulled. 2) Some kind of automated test (if only there was some kind of software package that could run integration tests after a software build, on a continuous basis) should be in place to load the nightly builds on each major OS and if they fail, then take action (back out submit, flag for review and don't release to public, any number of potential actions here) 3) Regarding a warning on the front page.. I disagree. Not because I feel that the people suggesting this are wrong, but it promotes bad behavior/poor code. The Jenkins community responsible for the stability of the product should take steps to reduce the possibility of a bugs like this making it to release-phase, instead of saying "meh, these things happen!".

          Eric Han added a comment -

          Same with me, and I tried multiple approaches on windows 7 64, the last works version is 1.539.
          Is there any workaround for changing the jenkins or JVM settings?

          Eric Han added a comment - Same with me, and I tried multiple approaches on windows 7 64, the last works version is 1.539. Is there any workaround for changing the jenkins or JVM settings?

          I rejected JENKINS-20722 because duplicate this. Is this problem related with Java 7?

          I have tested java versions :

          • 1.7.0.40 x86 - x64
          • 1.7.0.45 x86 - x64

          With and without tomcat on windows 2008 and 7

          Fernando Rosado Altamirano added a comment - I rejected JENKINS-20722 because duplicate this. Is this problem related with Java 7? I have tested java versions : 1.7.0.40 x86 - x64 1.7.0.45 x86 - x64 With and without tomcat on windows 2008 and 7

          Hal Deadman added a comment -

          I was having the problem with older versions of Java 7 and Java 6. It must be a general issue with Java on windows (and is triggered by something new in Jenkins). I was getting the crash on a Windows 2003 32-bit virtual machine. Specific versions of Java don't appear to be a factor and people have seen the problem on Windows 7, Windows 8, 2008, 2003, and 64bit and 32bit. The common thread appears to be a crash on windows during finalization and it occurs pretty quickly during startup. I have lots of plugins but it sounds like at least some people have gotten the problem by just running the latest war by itself on a fresh install.

          Hal Deadman added a comment - I was having the problem with older versions of Java 7 and Java 6. It must be a general issue with Java on windows (and is triggered by something new in Jenkins). I was getting the crash on a Windows 2003 32-bit virtual machine. Specific versions of Java don't appear to be a factor and people have seen the problem on Windows 7, Windows 8, 2008, 2003, and 64bit and 32bit. The common thread appears to be a crash on windows during finalization and it occurs pretty quickly during startup. I have lots of plugins but it sounds like at least some people have gotten the problem by just running the latest war by itself on a fresh install.

          boris ivan added a comment -

          Does anyone use Windows and not see this problem? I can't make the problem go away regardless what version of Windows/Java we use.

          boris ivan added a comment - Does anyone use Windows and not see this problem? I can't make the problem go away regardless what version of Windows/Java we use.

          Matt Kraai added a comment -

          Jenkins 1.541 also fails to start in the same way.

          Matt Kraai added a comment - Jenkins 1.541 also fails to start in the same way.

          Arpit Nagar added a comment -

          Same issue with us as well. please provide a Fix.

          Arpit Nagar added a comment - Same issue with us as well. please provide a Fix.

          Jason Yang added a comment -

          have the same issue:
          windows sever 2003 R2
          vmvare
          tomcat 7.0
          JRE 1.7.0

          Jason Yang added a comment - have the same issue: windows sever 2003 R2 vmvare tomcat 7.0 JRE 1.7.0

          Paul Grove added a comment -

          I have tried running Jenkins 1.541 on Windows 8.1 with Java 7 (b45) and it crashes Java. I then tried to deploy inside Tomcat 7, Tomcat starts but when I drop the jenkins war into tomcat it again causes Java to crash, strange thing is Java was not core dumping. To see if this was a Java 7 issue I tried on a different Windows machine running Windows 7 and Java 6. But Java crashed again at least this time Java 6 gave a core dump, which I have attached.

          I then tried the latest LTS version and this works fine.

          Paul Grove added a comment - I have tried running Jenkins 1.541 on Windows 8.1 with Java 7 (b45) and it crashes Java. I then tried to deploy inside Tomcat 7, Tomcat starts but when I drop the jenkins war into tomcat it again causes Java to crash, strange thing is Java was not core dumping. To see if this was a Java 7 issue I tried on a different Windows machine running Windows 7 and Java 6. But Java crashed again at least this time Java 6 gave a core dump, which I have attached. I then tried the latest LTS version and this works fine.

          Paul Grove added a comment -

          Java core dump from Jenkins start crash

          Paul Grove added a comment - Java core dump from Jenkins start crash

          In my opinion, all newer releases since 1.540 should be rejected - because, it's a major bug.
          Okay - as I know - "only" Windows-users are affected; But, as long as this problem exists,
          further weekly builds should be marked as unstable (or a similiar meaning).

          Markus Eisenmann added a comment - In my opinion, all newer releases since 1.540 should be rejected - because, it's a major bug. Okay - as I know - "only" Windows-users are affected; But, as long as this problem exists, further weekly builds should be marked as unstable (or a similiar meaning).

          Have same exact issue just had to roll back to 1.534

          Stephen Barrett added a comment - Have same exact issue just had to roll back to 1.534

          I tried 1.541 and had the same issues. I rolled back to 1.539 and everything seems to be working again.

          Shannon Newbold added a comment - I tried 1.541 and had the same issues. I rolled back to 1.539 and everything seems to be working again.

          @Markus, if the info on JENKINS-20764 is correct, it says
          Environment: Ubuntu 13, Java 1.6
          then it means that the issue affects both Windows and Linux users.
          https://issues.jenkins-ci.org/browse/JENKINS-20764

          Gemini Agaloos added a comment - @Markus, if the info on JENKINS-20764 is correct, it says Environment: Ubuntu 13, Java 1.6 then it means that the issue affects both Windows and Linux users. https://issues.jenkins-ci.org/browse/JENKINS-20764

          Matt Kraai added a comment -

          I used git bisect to determine that 7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be was the first commit that had this problem.

          Matt Kraai added a comment - I used git bisect to determine that 7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be was the first commit that had this problem.

          Oleg Nenashev added a comment -

          Thank you for analysis, Matt
          You are right, the error has been caused by Kernel32 call in https://github.com/jenkinsci/jenkins/commit/7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be

          Oleg Nenashev added a comment - Thank you for analysis, Matt You are right, the error has been caused by Kernel32 call in https://github.com/jenkinsci/jenkins/commit/7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/src/main/java/hudson/util/jna/Kernel32Utils.java
          http://jenkins-ci.org/commit/jenkins/0438e4f7a2142c1d18652aa7bcf8c3d72443f6af
          Log:
          [FIXED JENKINS-20630]

          The size is in wchar_t, not in bytes

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/util/jna/Kernel32Utils.java http://jenkins-ci.org/commit/jenkins/0438e4f7a2142c1d18652aa7bcf8c3d72443f6af Log: [FIXED JENKINS-20630] The size is in wchar_t, not in bytes

          Folks, my sincere apologies.

          Kohsuke Kawaguchi added a comment - Folks, my sincere apologies.

          The fix will be in 1.542.

          Kohsuke Kawaguchi added a comment - The fix will be in 1.542.

          Thanks for the fix. No hard feelings Kohsuke, everyone makes bugs We should figure out how it got past testing though.

          Stephen Barrett added a comment - Thanks for the fix. No hard feelings Kohsuke, everyone makes bugs We should figure out how it got past testing though.

          boris ivan added a comment -

          Hi Kohsuke,

          Jenkins-ci.org says that the latest release is 1.542, but the changelog for 'upcoming changes' for 1.542 shows 4 bug fixes, none of which are 20630. Can you confirm that this fix is in? If so, should it be in the changelog list? Thanks in advance.

          boris ivan added a comment - Hi Kohsuke, Jenkins-ci.org says that the latest release is 1.542, but the changelog for 'upcoming changes' for 1.542 shows 4 bug fixes, none of which are 20630. Can you confirm that this fix is in? If so, should it be in the changelog list? Thanks in advance.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3083
          [FIXED JENKINS-20630] (Revision 0438e4f7a2142c1d18652aa7bcf8c3d72443f6af)

          Result = SUCCESS
          kohsuke : 0438e4f7a2142c1d18652aa7bcf8c3d72443f6af
          Files :

          • core/src/main/java/hudson/util/jna/Kernel32Utils.java
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3083 [FIXED JENKINS-20630] (Revision 0438e4f7a2142c1d18652aa7bcf8c3d72443f6af) Result = SUCCESS kohsuke : 0438e4f7a2142c1d18652aa7bcf8c3d72443f6af Files : core/src/main/java/hudson/util/jna/Kernel32Utils.java changelog.html

          Lucien Weller added a comment -

          Tried Release 1.542 deployed on Glassfish on Windows, but still doesn't boot. Rolled back to 1.539

          Lucien Weller added a comment - Tried Release 1.542 deployed on Glassfish on Windows, but still doesn't boot. Rolled back to 1.539

          Linards L added a comment - - edited

          Still not fully functional. Reverted to v1.529.

          After first upgrade from v1.529 - it booted. After I updated more than 10 plugins and restarted ( second time, no jobs were finished / launched ) jenkins with v1.542, it again died with Jetty issues / spam in logs.

          My updated plugins:

          Artifactory Plugin
          This plugin allows deploying Maven 2, Maven 3, Ivy and Gradle artifacts and build info to the Artifactory artifacts manager.
          2.2.1 (2.1.7)

          Credentials Plugin
          This plugin allows you to store credentials in Jenkins.
          1.9.3 1.6

          CVS Plugin
          This bundled plugin integrates Jenkins with CVS version control system.
          2.11 2.9

          Disk Usage Plugin
          This plugin records disk usage.
          0.23 0.20

          HTML Publisher Plugin
          1.3 1.2

          JIRA Plugin
          This plugin integrates Atlassian JIRA to Jenkins.
          Brīdinājums: Šis spraudnis ir paredzēts Jenkins 1.533 un jaunākai versijai. Tas var gan strādāt, gan nestrādāt ar Jūsu Jenkins instalāciju.
          1.39 (1.36)

          JobConfigHistory Plugin
          Saves copies of all job and system configurations.
          2.5 2.4

          Maven Project Plugin
          Jenkins plugin for building Maven 2/3 jobs via a special project type.
          Brīdinājums: Šis spraudnis ir paredzēts Jenkins 1.532 un jaunākai versijai. Tas var gan strādāt, gan nestrādāt ar Jūsu Jenkins instalāciju.
          2.0 1.529

          Monitoring external jobs
          Adds the ability to monitor the result of externally executed jobs.
          1.2 1.1

          Nested View Plugin
          View type to allow grouping job views into multiple levels instead of one big list of tabs.
          1.14 1.10

          Parameterized Trigger Plugin
          This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build.
          2.21 2.20

          SSH Credentials Plugin
          This plugin allows you to store SSH credentials in Jenkins.
          Brīdinājums: Jaunā versija nav savietojama ar esošo uzstādīto spraudņa versiju. Jobs, kuri izmanto šo spraudni, var būt par iemeslu šo Jobu pārkonfigurācijai.
          1.6 0.3

          SSH Slaves plugin
          This plugin allows you to manage slaves running on *nix machines over SSH.
          Brīdinājums: Jaunā versija nav savietojama ar esošo uzstādīto spraudņa versiju. Jobs, kuri izmanto šo spraudni, var būt par iemeslu šo Jobu pārkonfigurācijai.
          1.5 0.25

          Subversion Plugin
          This plugin adds the Subversion support (via SVNKit) to Jenkins.
          1.54 1.51

          Warnings Plugin
          This plugin generates the trend report for compiler warnings in the console log or in log files.
          4.38 4.35

          Linards L added a comment - - edited Still not fully functional. Reverted to v1.529. After first upgrade from v1.529 - it booted. After I updated more than 10 plugins and restarted ( second time, no jobs were finished / launched ) jenkins with v1.542, it again died with Jetty issues / spam in logs. My updated plugins: Artifactory Plugin This plugin allows deploying Maven 2, Maven 3, Ivy and Gradle artifacts and build info to the Artifactory artifacts manager. 2.2.1 (2.1.7) Credentials Plugin This plugin allows you to store credentials in Jenkins. 1.9.3 1.6 CVS Plugin This bundled plugin integrates Jenkins with CVS version control system. 2.11 2.9 Disk Usage Plugin This plugin records disk usage. 0.23 0.20 HTML Publisher Plugin 1.3 1.2 JIRA Plugin This plugin integrates Atlassian JIRA to Jenkins. Brīdinājums: Šis spraudnis ir paredzēts Jenkins 1.533 un jaunākai versijai. Tas var gan strādāt, gan nestrādāt ar Jūsu Jenkins instalāciju. 1.39 (1.36) JobConfigHistory Plugin Saves copies of all job and system configurations. 2.5 2.4 Maven Project Plugin Jenkins plugin for building Maven 2/3 jobs via a special project type. Brīdinājums: Šis spraudnis ir paredzēts Jenkins 1.532 un jaunākai versijai. Tas var gan strādāt, gan nestrādāt ar Jūsu Jenkins instalāciju. 2.0 1.529 Monitoring external jobs Adds the ability to monitor the result of externally executed jobs. 1.2 1.1 Nested View Plugin View type to allow grouping job views into multiple levels instead of one big list of tabs. 1.14 1.10 Parameterized Trigger Plugin This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build. 2.21 2.20 SSH Credentials Plugin This plugin allows you to store SSH credentials in Jenkins. Brīdinājums: Jaunā versija nav savietojama ar esošo uzstādīto spraudņa versiju. Jobs, kuri izmanto šo spraudni, var būt par iemeslu šo Jobu pārkonfigurācijai. 1.6 0.3 SSH Slaves plugin This plugin allows you to manage slaves running on *nix machines over SSH. Brīdinājums: Jaunā versija nav savietojama ar esošo uzstādīto spraudņa versiju. Jobs, kuri izmanto šo spraudni, var būt par iemeslu šo Jobu pārkonfigurācijai. 1.5 0.25 Subversion Plugin This plugin adds the Subversion support (via SVNKit) to Jenkins. 1.54 1.51 Warnings Plugin This plugin generates the trend report for compiler warnings in the console log or in log files. 4.38 4.35

          This issue is being wrongly listed in the changelog as "26030" (instead of "20630"), leading to a deceiving "Issue Does Not Exist" JIRA page.

          [1] http://jenkins-ci.org/changelog

          Helder Magalhães added a comment - This issue is being wrongly listed in the changelog as "26030" (instead of "20630"), leading to a deceiving "Issue Does Not Exist" JIRA page. [1] http://jenkins-ci.org/changelog

          Code changed in jenkins
          User: Harald Albers
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/e7462a1bc3b2ebe07dd57e98a8d6ae405bd69c62
          Log:
          fixed invalid link for JENKINS-20630

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Harald Albers Path: changelog.html http://jenkins-ci.org/commit/jenkins/e7462a1bc3b2ebe07dd57e98a8d6ae405bd69c62 Log: fixed invalid link for JENKINS-20630

          cforce added a comment -

          @Linards L Please post ur error logs. Did you test with Jenkins 1.543?

          cforce added a comment - @Linards L Please post ur error logs. Did you test with Jenkins 1.543?

          Linards L added a comment - - edited

          @cforce,

          I will do it now, but it will not be valid test anymore because once I reverted to v1.529, I updated plugins. So it might work now, but it does not cover the issue I had earlier - crash after second reboot ( after plugins update ).

          Test scenarion:

          1. Up and running jenkins v1.529 with master and three slaves; All slaves offline;
          2. Plugins - all updated ( from my last attempt ( see date of my previous comment here ));
          3. Creating a slave ; installing as windows service ; starting it - up and running;
          3.1 Updating java to 1.7u45 ;
          3.2 Cannot launch slave-agent.jnlp because previously FAILED installation left old jars in slave directory. I had to delete them to make slave-agent.jlpn connectable, so I could install it as service.
          4. Performing automatic upgrade with one job running and one in queue ; waiting till it finishes;

          Resulting in error from console before returning

          Finished: SUCCESS

          in console:

          ln builds\lastStableBuild c:\jenkins_master\jobs\trunk-build\lastStable failed
          java.nio.file.DirectoryNotEmptyException: c:\jenkins_master\jobs\trunk-ExportDlls\lastStable
          	at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
          	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source)
          	at java.nio.file.Files.deleteIfExists(Unknown Source)
          	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          	at java.lang.reflect.Method.invoke(Unknown Source)
          	at hudson.Util.createSymlinkJava7(Util.java:1146)
          	at hudson.Util.createSymlink(Util.java:1070)
          	at hudson.model.AbstractBuild.createSymlink(AbstractBuild.java:494)
          	at hudson.model.AbstractBuild.access$700(AbstractBuild.java:105)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729)
          	at hudson.model.Run.execute(Run.java:1628)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:247)
          

          5. Rebooting jenkins;
          6. Updating plugins, if available.

          Plugins to be updated:

          Credentials Plugin
          This plugin allows you to store credentials in Jenkins.
          1.9.4 1.9.3

          LDAP Plugin
          Security realm based on LDAP authentication.
          1.7 1.6

          Mailer
          This plugin allows you to configure email notifications. This is a break-out of the original core based email component.
          1.6 1.5

          Throttle Concurrent Builds Plugin
          This plugin allows for throttling the number of concurrent builds of a project running per node or globally.
          1.8.1 1.8

          7. Checking result...

          	
          [!] Error
          
          hudson.util.HudsonFailedToLoad: org.jvnet.hudson.reactor.ReactorException: java.lang.NullPointerException
          	at hudson.WebAppMain$3.run(WebAppMain.java:234)
          Caused by: org.jvnet.hudson.reactor.ReactorException: java.lang.NullPointerException
          	at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:269)
          	at jenkins.InitReactorRunner.run(InitReactorRunner.java:44)
          	at jenkins.model.Jenkins.executeReactor(Jenkins.java:908)
          	at jenkins.model.Jenkins.<init>(Jenkins.java:807)
          	at hudson.model.Hudson.<init>(Hudson.java:82)
          	at hudson.model.Hudson.<init>(Hudson.java:78)
          	at hudson.WebAppMain$3.run(WebAppMain.java:222)
          Caused by: java.lang.NullPointerException
          	at java.io.Reader.<init>(Unknown Source)
          	at java.io.InputStreamReader.<init>(Unknown Source)
          	at org.codehaus.groovy.runtime.DefaultGroovyMethods.getText(DefaultGroovyMethods.java:16092)
          	at groovy.lang.GroovyShell$7.run(GroovyShell.java:714)
          	at groovy.lang.GroovyShell$7.run(GroovyShell.java:711)
          	at java.security.AccessController.doPrivileged(Native Method)
          	at groovy.lang.GroovyShell.parse(GroovyShell.java:711)
          	at groovy.lang.GroovyShell.parse(GroovyShell.java:790)
          	at hudson.util.spring.BeanBuilder.parse(BeanBuilder.java:133)
          	at hudson.security.SecurityRealm.createFilter(SecurityRealm.java:426)
          	at hudson.security.HudsonFilter.reset(HudsonFilter.java:140)
          	at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:2048)
          	at jenkins.model.Jenkins$20.run(Jenkins.java:2631)
          	at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
          	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
          	at jenkins.model.Jenkins$7.runTask(Jenkins.java:897)
          	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
          	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          	at java.lang.Thread.run(Unknown Source)
          

          jenkins.err: http://pastie.org/8550005


          I general, in each stage there was some small issues. This is definelty NOT fixed.

          Linards L added a comment - - edited @cforce, I will do it now, but it will not be valid test anymore because once I reverted to v1.529, I updated plugins. So it might work now, but it does not cover the issue I had earlier - crash after second reboot ( after plugins update ). Test scenarion: 1. Up and running jenkins v1.529 with master and three slaves; All slaves offline; 2. Plugins - all updated ( from my last attempt ( see date of my previous comment here )); 3. Creating a slave ; installing as windows service ; starting it - up and running; 3.1 Updating java to 1.7u45 ; 3.2 Cannot launch slave-agent.jnlp because previously FAILED installation left old jars in slave directory. I had to delete them to make slave-agent.jlpn connectable, so I could install it as service. 4. Performing automatic upgrade with one job running and one in queue ; waiting till it finishes; Resulting in error from console before returning Finished: SUCCESS in console: ln builds\lastStableBuild c:\jenkins_master\jobs\trunk-build\lastStable failed java.nio.file.DirectoryNotEmptyException: c:\jenkins_master\jobs\trunk-ExportDlls\lastStable at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source) at java.nio.file.Files.deleteIfExists(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.Util.createSymlinkJava7(Util.java:1146) at hudson.Util.createSymlink(Util.java:1070) at hudson.model.AbstractBuild.createSymlink(AbstractBuild.java:494) at hudson.model.AbstractBuild.access$700(AbstractBuild.java:105) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729) at hudson.model.Run.execute(Run.java:1628) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) 5. Rebooting jenkins; 6. Updating plugins, if available. Plugins to be updated: Credentials Plugin This plugin allows you to store credentials in Jenkins. 1.9.4 1.9.3 LDAP Plugin Security realm based on LDAP authentication. 1.7 1.6 Mailer This plugin allows you to configure email notifications. This is a break-out of the original core based email component. 1.6 1.5 Throttle Concurrent Builds Plugin This plugin allows for throttling the number of concurrent builds of a project running per node or globally. 1.8.1 1.8 7. Checking result... [!] Error hudson.util.HudsonFailedToLoad: org.jvnet.hudson.reactor.ReactorException: java.lang.NullPointerException at hudson.WebAppMain$3.run(WebAppMain.java:234) Caused by: org.jvnet.hudson.reactor.ReactorException: java.lang.NullPointerException at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:269) at jenkins.InitReactorRunner.run(InitReactorRunner.java:44) at jenkins.model.Jenkins.executeReactor(Jenkins.java:908) at jenkins.model.Jenkins.<init>(Jenkins.java:807) at hudson.model.Hudson.<init>(Hudson.java:82) at hudson.model.Hudson.<init>(Hudson.java:78) at hudson.WebAppMain$3.run(WebAppMain.java:222) Caused by: java.lang.NullPointerException at java.io.Reader.<init>(Unknown Source) at java.io.InputStreamReader.<init>(Unknown Source) at org.codehaus.groovy.runtime.DefaultGroovyMethods.getText(DefaultGroovyMethods.java:16092) at groovy.lang.GroovyShell$7.run(GroovyShell.java:714) at groovy.lang.GroovyShell$7.run(GroovyShell.java:711) at java.security.AccessController.doPrivileged(Native Method) at groovy.lang.GroovyShell.parse(GroovyShell.java:711) at groovy.lang.GroovyShell.parse(GroovyShell.java:790) at hudson.util.spring.BeanBuilder.parse(BeanBuilder.java:133) at hudson.security.SecurityRealm.createFilter(SecurityRealm.java:426) at hudson.security.HudsonFilter.reset(HudsonFilter.java:140) at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:2048) at jenkins.model.Jenkins$20.run(Jenkins.java:2631) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282) at jenkins.model.Jenkins$7.runTask(Jenkins.java:897) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang. Thread .run(Unknown Source) jenkins.err: http://pastie.org/8550005 I general, in each stage there was some small issues. This is definelty NOT fixed.

          Linards L added a comment - - edited

          Repeated update process.

          Now only updatable plugin was:

          Parameterized Trigger Plugin
          This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build.
          2.22 2.21

          Result is the same. First reboot is ok. Second - after updating plugin - total crash. Again back to v1.529.

          Linards L added a comment - - edited Repeated update process. Now only updatable plugin was: Parameterized Trigger Plugin This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build. 2.22 2.21 Result is the same. First reboot is ok. Second - after updating plugin - total crash. Again back to v1.529.

          Daniel Beck added a comment -

          Linards L: The error you describe seems to be completely different from the original error. It looks like something's wrong with your (security realm?) configuration. What makes you think your error is the same as, or even just related to the original issue reported here?

          (Also, just in case you didn't know this: Every new comment and edit of a comment here gets send via email to everyone watching this issue, almost 70 people. 15 such notifications in two hours like the day before yesterday is a bit much. Maybe consider keeping the number of edits down.)

          Daniel Beck added a comment - Linards L: The error you describe seems to be completely different from the original error. It looks like something's wrong with your (security realm?) configuration. What makes you think your error is the same as, or even just related to the original issue reported here? (Also, just in case you didn't know this: Every new comment and edit of a comment here gets send via email to everyone watching this issue, almost 70 people. 15 such notifications in two hours like the day before yesterday is a bit much. Maybe consider keeping the number of edits down.)

          K P added a comment -

          The issue by Linards L seems to be completely unrelated to the issue reported here.
          It would be better to create a different issue report for that, because "poluting" this issue with an unrelated issue is going to confuse people and makes it a mess to still see clearly through the issue comments, which isn't helping the original issue getting solved at all.

          K P added a comment - The issue by Linards L seems to be completely unrelated to the issue reported here. It would be better to create a different issue report for that, because "poluting" this issue with an unrelated issue is going to confuse people and makes it a mess to still see clearly through the issue comments, which isn't helping the original issue getting solved at all.

          Linards L added a comment -

          Sorry for mess.

          Created new issue: https://issues.jenkins-ci.org/browse/JENKINS-21018

          Thanks again.

          Linards L added a comment - Sorry for mess. Created new issue: https://issues.jenkins-ci.org/browse/JENKINS-21018 Thanks again.

          Daniel Beck added a comment -

          Marking as resolved again, as the user who reopened it appears to be affected by a different issue.

          Daniel Beck added a comment - Marking as resolved again, as the user who reopened it appears to be affected by a different issue.

            kohsuke Kohsuke Kawaguchi
            kraai Matt Kraai
            Votes:
            58 Vote for this issue
            Watchers:
            66 Start watching this issue

              Created:
              Updated:
              Resolved: