-
Bug
-
Resolution: Fixed
-
Blocker
-
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
-
Powered by SuggestiMate
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.
- hs_err_pid1000.log
- 17 kB
- hs_err_pid1788.log
- 22 kB
- hs_err_pid35184.log
- 24 kB
- hs_err_pid4584.log
- 13 kB
- hs_err_pid4968.log
- 20 kB
- hs_err_pid5660.log
- 21 kB
- hs_err_pid5960.log
- 21 kB
- jenkins.out.log
- 0.8 kB
- is duplicated by
-
JENKINS-20757 jenkins startup dies quickly ostensibly due to maven problem in 1.540 and 1.541
-
- Resolved
-
-
JENKINS-20765 Jenkins 1.541 make java hangs on windows
-
- Resolved
-
-
JENKINS-20779 Jenkins 1.541 crashes JVM on startup
-
- Closed
-
-
JENKINS-20722 Unable to start Jenkins 540 using java7u45x64b
-
- Closed
-
-
JENKINS-20809 JVM Crash during startup
-
- Closed
-
- is related to
-
JENKINS-20685 After Upgrading Jenkins It's Not Starting
-
- Resolved
-
-
JENKINS-20675 Java platform binary has stopped working message appears when starting Jenkins 1.540
-
- Resolved
-
-
JENKINS-10582 slave connection breaks thru EXCEPTION_ACCESS_VIOLATION
-
- Closed
-
-
JENKINS-20722 Unable to start Jenkins 540 using java7u45x64b
-
- Closed
-
[JENKINS-20630] Jenkins fails to start
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.
Fails to start:
-
- Windows 2008 server running Apache Tomcat 7
Apache Tomcat 7 crashes
- Windows 2008 server running Apache Tomcat 7
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.
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
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
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, 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.
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.
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.
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?
@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 =)
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.
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.
@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:
- 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
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!".
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
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.
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.
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.
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).
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
I used git bisect to determine that 7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be was the first commit that had this problem.
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
Thanks for the fix. No hard feelings Kohsuke, everyone makes bugs We should figure out how it got past testing though.
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.
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
Tried Release 1.542 deployed on Glassfish on Windows, but still doesn't boot. Rolled back to 1.539
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.
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,
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
in console:Finished: SUCCESS
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.
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: 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.)
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.
Marking as resolved again, as the user who reopened it appears to be affected by a different issue.
+1. Running Win7 x64 as a service and got the same errors. Reverting to 1.539 works.