[
https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945406#comment-13945406
]
Scott commented on LOG4J2-570:
------------------------------
I have minimal experience with YourKit (no license), and slightly more with
Visual VM. Below are some instructions on how to detect if there is a memory
leak. My experience with these profiler tools is that it more difficult to
actually trace the cause of the memory leak. This is where Eclipse Memory
Analyzer ( https://www.eclipse.org/mat/ ) really shines (see other set of
instructions below). Regardless if you like eclipse or not the filtering,
searching, and object relationships (particularly to GC roots) provided by this
plugin are very helpful.
Profiler instructions (visual VM and should work for YourKit):
1) Load the test webapp into your servlet container (tomcat).
2) Find your servlet container in your favorite profiler.
3) Take a heap dump.
4) In the heap dump look for all instances of class
"org.apache.catalina.loader.WebappClassLoader". There should be 1 instance of
this class for each webapp that is loaded (started in tomcat's case). Inspect
the "contextName" of each (assuming there is more than 1) instance until it
matches your test application name.
5) Stop your test webapp.
6) Take a heap dump.
7) There should now be 1 less instance of class
"org.apache.catalina.loader.WebappClassLoader". I am claiming there is not 1
less and this is the memory leak.
8) This is the step where YourKit and Visual VM where not so helpful...You want
to find all non-weak/non-soft references from this object to all GC roots. For
example Visual VM in the Out References you can right click "this" and "Show
Nearest GC Root" but this does not yield very much context (often givens
something general like a Task Thread). If you have a way to do this with Your
Kit or another profiler tool please let me know.
Eclipse Memory Analyzer (Eclipse Kepler) Instructions:
1) Take a heap dump (File->New->Other->Other->Heap Dump)
2) Select your application (Description=org.apache.catalina.startup.Boostrap
start).
3) Select anything but "Re-open previously run reports" (i.e. "Leak Suspects
Report")
4) Click the "Open Dominator Tree for entire heap" (third button from left in
heap report)
5) Search for "org.apache.catalina.loader.WebappClassLoader"
6) Inspect each instance to find the instance which references your web
application (look at strings to find paths to your JARs)
7) Trace this instance back to GC roots (Right click->Path to GC Roots->exclude
weak/soft references).
8) In this case you should see an instance of class
"org.apache.logging.log4j.core.jmx.LoggerContextAdmin" which is holding on to a
reference.
> Memory Leak
> -----------
>
> Key: LOG4J2-570
> URL: https://issues.apache.org/jira/browse/LOG4J2-570
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04
> Linux bos-lpuv7 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
> 8 GB RAM
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60
> -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true
> -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC
> -XX:+CMSClassUnloadingEnabled
> <log4j.version>2.0-rc1</log4j.version>
> log4j-api
> log4j-core
> log4j-jcl
> Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in
> tomcat7.0.52 container.
> Reporter: Scott
> Assignee: Matt Sicker
> Priority: Blocker
> Fix For: 2.0-rc2
>
> Attachments: spring_log4j2_memory_leak.tbz2
>
>
> Dynamically loading a JAR that uses log4j2 results in a memory leak when the
> JAR is unloaded. This can be observed by deploying a web application to
> tomcat7 and exercising the stop, undeploy, or redeploy actions. The memory
> leak is believed to be caused by log4j for the following reasons:
> 1)Heap Dump reveals the classloader instance responsible for the WAR plugin
> (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft
> reference which are of type
> (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and
> (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been
> stopped or undeployed.
> 2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output
> is equivalent but all memory is gc as expected (the
> org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no
> longer referenced by any hard references)
> 3)Using the SLF4J NOP logger implementation all memory is gc as expected (the
> org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no
> longer referenced by any hard references)
> This may not be unique to 2.0rc-1 and I have seen similar behavior in
> previous 2.0 beta releases.
> This is reproducible with a very simple spring hello world application. Code
> and/or heap dumps can be provided upon request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
