Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 1071695 - Infinite recursion when exception stack frame class lookup fails
Infinite recursion when exception stack frame class lookup fails
Status: VERIFIED
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Logging (Show other bugs)
6.2.0
Unspecified Unspecified
urgent Severity urgent
: DR11
: EAP 6.4.0
Assigned To: James Perkins
Nikoleta Ziakova
:
Depends On: 1166437
Blocks:
  Show dependency tree / graph
 
Reported: 2014-03-02 18:31 EST by James Livingston
Modified: 2018-03-06 15:57 EST (History)
5 users (show)

See Also:
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: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker LOGMGR-99 Critical Resolved Infinite recursion when exception stack frame class lookup fails 2018-05-30 09:00 EDT
Red Hat Knowledge Base (Solution) 518953 None None None Never

  None (edit)
Description James Livingston 2014-03-02 18:31:28 EST 
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 16:51:58 EDT 
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 14:00:46 EDT 
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 11:23:05 EST 
Has a workaround, only affects a limited number of uses. It will still be in before cut off though.
Comment 7 Nikoleta Ziakova 2014-12-01 06:49:31 EST 
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.
First Last Prev Next    This bug is not in your last search results.