-
Bug
-
Resolution: Fixed
-
Critical
-
core 1.606
support bundle 2.20
With support bundle plugin installed, when I create a new logger and let the logger classname field empty, Jenkins crashes when I click Save button.
On save, Jenkins starts to write tons of exception logs and is not responsible anymore. Killing the JVM is the only way to stop it doing this.
Logged exception looks like this one:
Exception in thread "RequestHandlerThread[#10]" java.lang.ClassCircularityError: hudson/logging/LogRecorder at com.cloudbees.jenkins.support.impl.JenkinsLogs$CustomHandler.publish(JenkinsLogs.java:507) at java.util.logging.Logger.log(Logger.java:616) at java.util.logging.Logger.doLog(Logger.java:641) at java.util.logging.Logger.log(Logger.java:730) at org.eclipse.jetty.util.log.JavaUtilLog.warn(JavaUtilLog.java:70) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:698) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)
On 1.580, faulty configuration is saved on disk. To restart the instance, faulty configuration file $JENKINS_HOME/log/<faulty>.xml must be removed.
On 1.606, configuration is not saved, so restarting the instance works.
- is related to
-
-
- Resolved
-
- relates to
-
-
- Closed
-
-
JENKINS-62472 Require confirmation before configuring root logger to high log level
-
- Open
-
- links to
[JENKINS-27669] Creating an empty logger crashs Jenkins
Yoann Dubreuil
created issue -
| Assignee | Original: Steven Christou [ schristou ] | New: Jesse Glick [ jglick ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Status | Original: In Progress [ 3 ] | New: Open [ 1 ] |
Yoann can you still reproduce this? I could not. I started a dev version of support-core on 1.606, created a new log recorder, added a logger with the blank name (logging ALL), and saved. It produced lots of messages, to be sure, but Jenkins did not crash.
| Assignee | Original: Jesse Glick [ jglick ] | New: Yoann Dubreuil [ ydubreuil ] |
Yoann Dubreuil
added a comment - Jesse, I can't reproduce on a dev environment either (tried on 1.554 core). But I'm still able to reproduce by starting a standalone OSS 1.606 war and installing the latest support-core plugin manually.
Yoann Dubreuil
added a comment - Jesse, I can't reproduce on a dev environment either (tried on 1.554 core). But I'm still able to reproduce by starting a standalone OSS 1.606 war and installing the latest support-core plugin manually. | Assignee | Original: Yoann Dubreuil [ ydubreuil ] | New: Jesse Glick [ jglick ] |
Interesting…after having run 1.606, created the empty logger, deleted it, I tried to install Support Core (2.21) in the same session and got linkage errors, for example
java.lang.ClassCircularityError: java/util/Map$Entry at com.cloudbees.jenkins.support.impl.JenkinsLogs$CustomHandler.publish(JenkinsLogs.java:506) at java.util.logging.Logger.log(Logger.java:738) at java.util.logging.Logger.doLog(Logger.java:765) at java.util.logging.Logger.log(Logger.java:788) at org.eclipse.jetty.util.log.JavaUtilLog.debug(JavaUtilLog.java:108) at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:439) at java.lang.ClassLoader.loadClass(ClassLoader.java:411) at hudson.util.MaskingClassLoader.loadClass(MaskingClassLoader.java:62) at java.lang.ClassLoader.loadClass(ClassLoader.java:411) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at jenkins.util.AntClassLoader.findBaseClass(AntClassLoader.java:1397) at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1074) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2693) at java.lang.Class.getDeclaredMethods(Class.java:1967) at org.jvnet.hudson.annotation_indexer.Index$2$1.fetch(Index.java:102) at org.jvnet.hudson.annotation_indexer.Index$2$1.hasNext(Index.java:72) at org.jvnet.hudson.annotation_indexer.SubtypeIterator.fetch(SubtypeIterator.java:18) at org.jvnet.hudson.annotation_indexer.SubtypeIterator.hasNext(SubtypeIterator.java:28) at hudson.init.TaskMethodFinder.discoverTasks(TaskMethodFinder.java:56) at hudson.init.InitializerFinder.discoverTasks(InitializerFinder.java:33) at hudson.PluginManager.dynamicLoad(PluginManager.java:479) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1318) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1121) at …
Seems to be a class loading order problem: this code loads Map.Entry for the first time (seems impossible!), which in turns triggers class loading, which the JVM rejects since we are already loading a class.
Without support-core, it works fine. An empty value is legal, as it is in java.util.logging generally.