Bug 1071695 - Infinite recursion when exception stack frame class lookup fails
Summary: Infinite recursion when exception stack frame class lookup fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Logging
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: DR11
: EAP 6.4.0
Assignee: James Perkins
QA Contact: Nikoleta Hlavickova
URL:
Whiteboard:
Depends On: 1166437
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-02 23:31 UTC by James Livingston
Modified: 2019-08-19 12:46 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker LOGMGR-99 0 Critical Resolved Infinite recursion when exception stack frame class lookup fails 2018-05-30 13:00:46 UTC
Red Hat Knowledge Base (Solution) 518953 0 None None None Never

Description James Livingston 2014-03-02 23:31:28 UTC
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)
       ...

Comment 3 James Perkins 2014-10-02 20:51:58 UTC
This is fixed in the upstream of jboss-logmanager. If no other issues popup soon I'll cut another release with this fix.

Comment 4 James Perkins 2014-10-08 18:00:46 UTC
I forgot to mention a simple work-around is to use %e instead of %E in the format pattern.

Comment 5 Jason T. Greene 2014-11-20 16:23:05 UTC
Has a workaround, only affects a limited number of uses. It will still be in before cut off though.

Comment 7 Nikoleta Hlavickova 2014-12-01 11:49:31 UTC
Verified with EAP 6.4.0.DR11 using reproducer at LOGMGR-99


Note You need to log in before you can comment on or make changes to this bug.