Bug 1071695
| Summary: | Infinite recursion when exception stack frame class lookup fails | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | James Livingston <jlivings> |
| Component: | Logging | Assignee: | James Perkins <jperkins> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Nikoleta Hlavickova <nziakova> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.2.0 | CC: | jason.greene, joallen, kkhan, ksato, onagano |
| Target Milestone: | DR11 | ||
| Target Release: | EAP 6.4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
The JBoss LogManager when configured with the %E formatter, prints out where the jar classes are from. If there is a problem loading the class, JBoss Modules prints a warning. In some circumstances, the exception formatter will trigger infinite recursion between the log manager loading a class and modules printing a warning.
This issue has been fixed in JBoss EAP 6.4. The situation no longer triggers infinite recursion and logging.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1166437 | ||
| Bug Blocks: | |||
This is fixed in the upstream of jboss-logmanager. If no other issues popup soon I'll cut another release with this fix. I forgot to mention a simple work-around is to use %e instead of %E in the format pattern. Has a workaround, only affects a limited number of uses. It will still be in before cut off though. Verified with EAP 6.4.0.DR11 using reproducer at LOGMGR-99 |
To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader. It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies. If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example ... at org.jboss.logmanager.Logger.log(Logger.java:367) at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73) at org.jboss.modules.Module.loadModuleClass(Module.java:527) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:266) at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578) at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421) at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388) at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150) at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) at org.jboss.logmanager.Logger.logRaw(Logger.java:721) at org.jboss.logmanager.Logger.logRaw(Logger.java:731) at org.jboss.logmanager.Logger.log(Logger.java:367) ...