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 "Gary Gregory (JIRA)" <ji...@apache.org> on 2016/10/10 20:43:20 UTC
[jira] [Commented] (LOG4J2-1634) Root LoggerConfig is corrupted
leading to stack overflow
[ https://issues.apache.org/jira/browse/LOG4J2-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563437#comment-15563437 ]
Gary Gregory commented on LOG4J2-1634:
--------------------------------------
[~rod.burgett@computer.org],
Thank you for your report.
Would you mind trying with our freshly minted 2.7 release?
Gary
> 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