Uploaded image for project: 'Maven Surefire'
  1. Maven Surefire
  2. SUREFIRE-2186

Memory Leaks when reusing the fork

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              clebertsuconic Clebert Suconic
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated: