[
https://issues.apache.org/jira/browse/SUREFIRE-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic updated SUREFIRE-2186:
--------------------------------------
Summary: Memory Leaks when reusing the fork (was: Leaks in Surefire when
reusing the fork)
> Memory Leaks when reusing the fork
> ----------------------------------
>
> Key: SUREFIRE-2186
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2186
> Project: Maven Surefire
> Issue Type: Bug
> Reporter: Clebert Suconic
> Priority: Major
>
> It is not possible to run a very extensive test suite with the current
> version of surefire when you reuse the forks.
> This used to work with surefire 2.22.2, and it's leaking with 3.1.2
> In ActiveMQ Artemis, we have thousands of integration tests and we reuse the
> forks otherwise it would take an infinite amount of time to complete the test
> suite. and we had to revert to surefire 2.22.2 until this leak is resolved.
> One obvious leak I see is
> org.apache.maven.surefire.api.util.internal.ClassMethod being held by
> ClassMethodIndexer, which is being held by Junit4RunListener.
> Also, a bit scary the fact that ClassMethodIndexer is using a non static
> ThreadLocal. even though this is not holding ClassMethod instances, but since
> my complain is the test suite not being able to finish with the new SureFire
> maybe this is also causing issues.
> I have been doing fine on pursuing leaks (even though it's not my main
> professional attribution :) but I created a pet project just for that
> purpose, if someone is interested in fixing this I will be certainly up to
> help fixing or even fixing it myself if I'm provided some guidance as I'm new
> to this codebase)
> To reproduce the ClassMethod leak validation, you should follow these steps:
> git clone https://github.com/clebertsuconic/surefire-reproducer.git
> cd surefire-reproducer
> mvn install
> The surefire-reproducer is using check-leak to count the number of
> ClassMethod instances in the HEAP.
> Notice there might be other leaks like the one I mentioned with the non
> static ThreadLocal. Or even Junit4Listener itself. as I think the instance
> should be released at the end of the test.
> BTW: Non static thread local is an anti-pattern. For example:
> https://errorprone.info/bugpattern/ThreadLocalUsage
> There are probably valid usecases with non static threadLocals, but I haven't
> seen one that couldn't be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
