[JIRA] (JENKINS-15552) envinject plugin v1.72 might be incompatible with Jenkins v.1486
Greg Allen commented on JENKINS-15552 envinject plugin v1.72 might be incompatible with Jenkins v.1486 I think one possible cause of this issue is if you aggressively clean the TEMP directory on the master or slave servers. It may be that removal of one of the remoting files that hudson/jenkins creates there causes this cryptic exception. Even the plain old Windows disk clean up might cause this. Perhaps Jenkins could lock these temp files while it runs so that they can't accidentally be deleted? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15552) envinject plugin v1.72 might be incompatible with Jenkins v.1486
Greg Allen commented on JENKINS-15552 envinject plugin v1.72 might be incompatible with Jenkins v.1486 Still seeing this, and have verified that it is not necessarily caused by a PermGen memory issue. Likely need to open a new JIRA issue for this. My main symptom is persistent failures from all builds on a slave, with exception of the form: java.io.InvalidClassException: hudson.FilePath$FileCallableWrapper; local class incompatible: stream classdesc Also seeing: Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jvnet.hudson.Windows$MEMORYSTATUSEX Restarting the slave always seems to clear the issue. Is a timeout during a diskspace monitoring attempt leaving a class in an unitialized state perhaps? 17-Nov-2012 09:18:16 hudson.node_monitors.AbstractNodeMonitorDescriptor$Record run WARNING: Failed to monitor lonws10509 for Free Swap Space java.io.IOException: Remote call on lonws10509 failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:83) at hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:81) at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:219) Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jvnet.hudson.Windows$MEMORYSTATUSEX at org.jvnet.hudson.Windows.monitor(Windows.java:40) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:113) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:99) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:619) Exception in thread "Monitoring lonws10894-psft_prd for Free Disk Space" java.lang.reflect.UndeclaredThrowableException at hudson.remoting.$Proxy6.fetch2(Unknown Source) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:122) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at java.io.ObjectStreamClass.getInheritableMethod(ObjectStreamClass.java:1349) at java.io.ObjectStreamClass.access$2200(ObjectStreamClass.java:52) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:448) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:413) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at hudson.remoting.UserRequest._serialize(UserRequest.java:155) at hudson.remoting.UserRequest.serialize(UserRequest.java:164) at hudson.remoting.UserRequest.perform(UserRequest.java:126) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at hudson.remoting.Request.call(Request.java:127) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:160) ... 27 more Exception in thread "Monitoring lonws10894-psft_prd for Free Temp Space" java.lang.reflect.UndeclaredThrowableException at
[JIRA] (JENKINS-15552) envinject plugin v1.72 might be incompatible with Jenkins v.1486
Greg Allen commented on JENKINS-15552 envinject plugin v1.72 might be incompatible with Jenkins v.1486 Having the same issue here, but do not have envinject plugin installed at all. Have found that restarting the affected slave temporarily prevents the error. Suspect that your "fix" actually works similarly due to the restart when removing the plugin. My only suspect cause is a minor difference in the JVM versions between master (1.6.0_26) and slave (1.6.0_21) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15552) envinject plugin v1.72 might be incompatible with Jenkins v.1486
Greg Allen commented on JENKINS-15552 envinject plugin v1.72 might be incompatible with Jenkins v.1486 Think I have found the solution: use the node's build history to find the first failed build. Likely you will find some other error that caused some class to fail initialization. In my case this was: 15:17:40.582 Caused by: java.lang.OutOfMemoryError: PermGen space 15:17:40.582 at hudson.security.PermissionScope.init(PermissionScope.java:70) 15:17:40.582 at hudson.security.PermissionScope.clinit(PermissionScope.java:95) 15:17:40.582 at hudson.security.Permission.init(Permission.java:178) 15:17:40.582 at hudson.security.Permission.clinit(Permission.java:291) 15:17:40.582 at hudson.scm.SCM.clinit(SCM.java:595) 15:17:40.582 at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:776) 15:17:40.582 at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:763) 15:17:40.582 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2308) 15:17:40.582 at hudson.remoting.UserRequest.perform(UserRequest.java:118) 15:17:40.598 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 15:17:40.598 at hudson.remoting.Request$2.run(Request.java:287) 15:17:40.598 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) 15:17:40.598 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 15:17:40.598 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 15:17:40.598 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 15:17:40.598 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 15:17:40.598 at hudson.remoting.Engine$1$1.run(Engine.java:60) 15:17:40.598 at java.lang.Thread.run(Thread.java:619) This very likely explain all your symptoms. Cryptically, because the class fails to initialize, it does not its serialVersionUID does not get initialized, and later the standard Serialization logic will equate this with a serial UID of 1, even though that's not really the case. Hence the unitialised class error turns into an unhelpful incompatible class error. Restarting the slave will of course "fix" the memory issue temporarily. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15692) Web navigation shortcuts for Next Build / Previous Build
Greg Allen created JENKINS-15692 Web navigation shortcuts for Next Build / Previous Build Issue Type: Improvement Assignee: Unassigned Components: core Created: 01/Nov/12 10:13 AM Description: Nice to have feature, as commonly seen on photo galleries, would be for the left and right keys to activate the next build and previous build links Project: Jenkins Priority: Minor Reporter: Greg Allen This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15248) Auto update violations unstable and heathly limits following a healthy build
Greg Allen created JENKINS-15248 Auto update violations unstable and heathly limits following a healthy build Issue Type: Improvement Assignee: peterkittreilly Components: violations Created: 20/Sep/12 11:07 AM Description: The coverage plugin recently got this feature - would be great to have the same for Violations Project: Jenkins Priority: Major Reporter: Greg Allen This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12514) .hpi versus .jpi causes inability to upgrade Subversion Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Allen reopened JENKINS-12514: -- not fixed on Windows in 1.456. Tried upgrading Subversion plugin from default 1.34 to latest 1.39 using plugin update page. new version gets downloaded and can be seen in the plugins directory. old .bak version of plugin is there too. However, on restart the newly downloaded subversion.jpi file seems to get overwritten, and the installed version is still 1.34. .hpi versus .jpi causes inability to upgrade Subversion Plugin -- Key: JENKINS-12514 URL: https://issues.jenkins-ci.org/browse/JENKINS-12514 Project: Jenkins Issue Type: Bug Components: update-center Environment: Ubuntu 11.10, OpenJDK 1.6.0_23, Tomcat 7.0.21, Jenkins 1.448 1.449 Reporter: Charlie Huggard Assignee: Kohsuke Kawaguchi Priority: Blocker Reproduction: $JENKINS_HOME/plugins: subversion (directory), subversion.hpi 1) Open http://root/pluginManager. Update Subversion plugin from 1.34 - 1.37 using download now and install after restart button. $JENKINS_HOME/plugins: subversion (directory), subversion.bak (1.34), subversion.hpi.pinned, subversion.jpi (1.37) 2) Restart Tomcat/Jenkins $JENKINS_HOME/plugins: subversion (directory), subversion.bak (1.34), subversion.hpi (1.34) subversion.hpi.pinned, subversion.jpi (1.37) 3) PluginManager still reports old version Should note that the logs report: INFO: Ignoring /ci/jenkins-home/plugins/subversion.jpi because /ci/jenkins-home/plugins/subversion.hpi is already loaded Also the plugin is broken at this point with a NoClassDefFound on org/tmatesoft/svn/core/SVNException Clean State: 1) /etc/init.d/tomcat7 stop 2) cd $JENKINS_HOME/plugins 3) rm subversion* 4) /etc/init.d/tomcat7 start Workaround: 1) Restore clean state 2) Update plugin 3) Stop tomcat/jenkins 4) cd $JENKINS_HOME/plugins 5) mv subversion.jpi subversion.hpi 6) Start tomcat/jenkins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12514) .hpi versus .jpi causes inability to upgrade Subversion Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Allen updated JENKINS-12514: - Environment: Ubuntu 11.10, OpenJDK 1.6.0_23, Tomcat 7.0.21, Jenkins 1.448 1.449 Jenkins 1.456 on Windows Server 2003 64-bit, Sun JDK 6.0.260.3 was:Ubuntu 11.10, OpenJDK 1.6.0_23, Tomcat 7.0.21, Jenkins 1.448 1.449 .hpi versus .jpi causes inability to upgrade Subversion Plugin -- Key: JENKINS-12514 URL: https://issues.jenkins-ci.org/browse/JENKINS-12514 Project: Jenkins Issue Type: Bug Components: update-center Environment: Ubuntu 11.10, OpenJDK 1.6.0_23, Tomcat 7.0.21, Jenkins 1.448 1.449 Jenkins 1.456 on Windows Server 2003 64-bit, Sun JDK 6.0.260.3 Reporter: Charlie Huggard Assignee: Kohsuke Kawaguchi Priority: Blocker Reproduction: $JENKINS_HOME/plugins: subversion (directory), subversion.hpi 1) Open http://root/pluginManager. Update Subversion plugin from 1.34 - 1.37 using download now and install after restart button. $JENKINS_HOME/plugins: subversion (directory), subversion.bak (1.34), subversion.hpi.pinned, subversion.jpi (1.37) 2) Restart Tomcat/Jenkins $JENKINS_HOME/plugins: subversion (directory), subversion.bak (1.34), subversion.hpi (1.34) subversion.hpi.pinned, subversion.jpi (1.37) 3) PluginManager still reports old version Should note that the logs report: INFO: Ignoring /ci/jenkins-home/plugins/subversion.jpi because /ci/jenkins-home/plugins/subversion.hpi is already loaded Also the plugin is broken at this point with a NoClassDefFound on org/tmatesoft/svn/core/SVNException Clean State: 1) /etc/init.d/tomcat7 stop 2) cd $JENKINS_HOME/plugins 3) rm subversion* 4) /etc/init.d/tomcat7 start Workaround: 1) Restore clean state 2) Update plugin 3) Stop tomcat/jenkins 4) cd $JENKINS_HOME/plugins 5) mv subversion.jpi subversion.hpi 6) Start tomcat/jenkins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13010) Impossible to use JavaScript at view's description
[ https://issues.jenkins-ci.org/browse/JENKINS-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=160187#comment-160187 ] Greg Allen commented on JENKINS-13010: -- Same issue seen here in 1.454 and 1.455. Breaks my nice google gauge :( Impossible to use JavaScript at view's description -- Key: JENKINS-13010 URL: https://issues.jenkins-ci.org/browse/JENKINS-13010 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: Daniel Tkatch # click Edit view # enter a script/script into the Description field that allows HTML and save - # script section has been filtered out and your script has no effect. This has been very helpful and stopped working with the last Jenkins update. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
