#162 Possible memory leak

release_3.1
closed
ANT Task (45)
5
2012-10-10
2003-10-14
Russ Collier
No

As I said in my mail to the checkstyle-user list, there
seems to be a memory leak in the Checkstyle v3.1 Ant
Task.

When the Ant task is used as part of a Java process
which runs the task (among many other things), sleeps,
then wakes up to run the same routine, memory is slowly
completely used up in the JVM (which eventually crashes
with java.lang.OutOfMemoryError). This only started
happening after the Checkstyle v3.1 Ant task was
introduced into my existing build system.

JProbe v4 was used to debug the process and numerous
instances of 'long[ ]' seem to be the culprit (being
allocated by something in the com.puppycrawl.tools
package). These instances never get cleaned up by the
gc.

This memory leak can be duplicated using Sun's JDK
1.3.1, Ant v1.5, Checkstyle v3.1 (Ant task), and a
wrapper process which runs Ant (via calls to the API),
sleeps, wakes up, and repeats indefinitely (attached).

Attached is a zip file containing 2 more zip files. One zip
file contains a simple test case to duplicate the leak,
along with the checkstyle_checks.xml file containing the
checks being applied in every case the leak was
observed. The second zip file contains a screen shot of
the JProbe memory debugger heap summary after 3
iterations of the aforementioned test case. There are
also 2 html files included with more indepth information
from the heap summary.

Discussion

  • Russ Collier
    Russ Collier
    2003-10-14

    Test case and memory debugger output

     
    Attachments
  • Logged In: YES
    user_id=746148

    Thank you for the test and other information.
    The problem is reproducible on windows with 3.1 (with
    both jdk1.3.1 and 1.4.2).

     
  • Logged In: YES
    user_id=746148

    It looks like the cause of the problem is that
    org.appache.tools.Project creates new class loader for every
    executeTarget() call, and keeps all created class loaders.
    Every class loader keeps references to all classes which were
    loaded using it (this means that all static data is locked and
    gc can not collects it)

     
  • Logged In: YES
    user_id=746148

    The problem is in build.xml. Taskdef task is in target we
    invoke. Thus ant creates new check style task every time
    we call executeTarget() (and so it creates new class loader
    for it). To fix this problem we should move taskdef tag to
    topmost level of build.xml. In this case ant creates the test
    only once. And we don't have problem with class loaders.

    I'm going to dig more over weekend, but I think that
    this is the real cause of the problem and so the correct way
    to fix it is change build.xml.

     
  • Logged In: YES
    user_id=746148

    I've verify that after moving taskdef to topmost level in
    build.xml, the test woks ok (w/o increasing memory usage) in
    my environment.
    Could you, please, confirm that this fixes the problem in your
    environment too.

     
  • Logged In: YES
    user_id=746148

    Based on the evaluation I close this bug as not a bug.
    If suggested fix is reproducible in your environment after
    moving taskdef then feel free to reopen it.