You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Rod Burgett (JIRA)" <ji...@apache.org> on 2016/10/07 11:48:20 UTC

[jira] [Created] (LOG4J2-1634) Root LoggerConfig is corrupted leading to stack overflow

Rod Burgett created LOG4J2-1634:
-----------------------------------

             Summary: Root LoggerConfig is corrupted leading to stack overflow
                 Key: LOG4J2-1634
                 URL: https://issues.apache.org/jira/browse/LOG4J2-1634
             Project: Log4j 2
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.6.2
            Reporter: Rod Burgett


The simple repro code below demonstrates the corruption of the LoggerConfig instance for root logger.  Executing the main leads to unstopped recursion, leading to stack overflow.  The recursion includes three method calls, shown in this stack trace fragment:

        at org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:381)
        at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:376)
        at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
        at org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:381)
        at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:376)
        at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
        at org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:381)
        at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:376)
        at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)

The basic problem is that 'logParent' becomes no-op (ends recursion) if additivity is off or if logger config's parent is null, otherwise recusrion continues.

In the repro case, the root logger config points to itself as parent.

I expect that when adding a logger to Configuration, the LoggerConfig should be specific to the named logger.  So, the stack overflow could be avoided if Configuration.addLogger checked that the LoggerConfig's name matched the input logger name.

Repro code:
    String loggerName = "new.logger.name";
    LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
    Configuration config = ctx.getConfiguration();
    LoggerConfig logCfg = config.getLoggerConfig(loggerName);
    config.addLogger(loggerName, logCfg);
    ctx.updateLoggers();
    LogManager.getLogger(loggerName).error("...by: "+loggerName+"....");




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org