[
https://issues.apache.org/jira/browse/LOG4J2-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Björn Kautler updated LOG4J2-2599:
----------------------------------
Description:
The attached project shows a {{StackOverflowError}} between the JUL binding and
the core artifact.
To make the error happen with *this* showcase example you have to use Java 11
or Java 12. This is because this exact showcase depends on a bug that does not
yet exist in Java 10 and is fixed in Java 13. But this does not mean the
problem is on the JDK side, this bug is only a requirement for this showcase
working as intended, but the bug could still be triggered by other bugfree
code, I just happened to have the reproducer that depends on this bug.
Setting the locale in this showcase is not relevant to Log4j, but to trigger
the bug in the JDK that will show the problem.
Basically the problem is, that during the
{{org.apache.logging.log4j.LogManager.getLogger}} call Log4j wants to
initialize the default logger with its default pattern, containing a {{%d}}.
This causes a {{GregorianCalendar}} to be created. Due to the bug, the class
wants to log something with the `PlatformLogger`, which is the essential part
of the problem. Because due to the JUL binding, this fires back to Log4j which
again wants to initialilze the default logger and the loop is closed until the
stack flows over.
was:
The attached project shows a {{StackOverflowError}} between the JUL binding and
the core artifact.
To make the error happen with *this* showcase example you have to use Java 11
or Java 12. This is because this exact showcase depends on a bug that does not
yet exist in Java 10 and is fixed in Java 13. But this does not mean the
problem is on the JDK side, this bug is only a requirement for this showcase
working as intended, but the bug could still be triggered by other bugfree
code, I just happened to have the reproducer that depends on this bug.
Setting the locale in this showcase is not relevant to Log4j, but to trigger
the bug in the JDK that will show the problem.
Basically the problem is, that during the
{{org.apache.logging.log4j.LogManager.getLogger}} call Log4j wants to
initialize the default logger with its default pattern, containing a `%d`. This
causes a {{GregorianCalendar}} to be created. Due to the bug, the class wants
to log something with the `PlatformLogger`, which is the essential part of the
problem. Because due to the JUL binding, this fires back to Log4j which again
wants to initialilze the default logger and the loop is closed until the stack
flows over.
> StackOverflowError between jul-binding and core
> -----------------------------------------------
>
> Key: LOG4J2-2599
> URL: https://issues.apache.org/jira/browse/LOG4J2-2599
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.11.2
> Reporter: Björn Kautler
> Priority: Major
> Attachments: foo.zip
>
>
> The attached project shows a {{StackOverflowError}} between the JUL binding
> and the core artifact.
> To make the error happen with *this* showcase example you have to use Java 11
> or Java 12. This is because this exact showcase depends on a bug that does
> not yet exist in Java 10 and is fixed in Java 13. But this does not mean the
> problem is on the JDK side, this bug is only a requirement for this showcase
> working as intended, but the bug could still be triggered by other bugfree
> code, I just happened to have the reproducer that depends on this bug.
> Setting the locale in this showcase is not relevant to Log4j, but to trigger
> the bug in the JDK that will show the problem.
> Basically the problem is, that during the
> {{org.apache.logging.log4j.LogManager.getLogger}} call Log4j wants to
> initialize the default logger with its default pattern, containing a {{%d}}.
> This causes a {{GregorianCalendar}} to be created. Due to the bug, the class
> wants to log something with the `PlatformLogger`, which is the essential part
> of the problem. Because due to the JUL binding, this fires back to Log4j
> which again wants to initialilze the default logger and the loop is closed
> until the stack flows over.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
