-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak (TestNG seems to keep all test object in memory) #1461
Comments
Thanks for the report. First, could you try with the latest version? Maybe it is already fixed. But, by design, TestNG is keeping objects in memory for its reporters. An option could be to disable them. |
This was a neat trick. I never knew one could do that :) Thanks for sharing this. TestNG testng = new TestNG() {
@Override
protected void finalize() throws Throwable {
// it seems that this object will never be finalized !!!
System.out.println("TestNG finalized");
}
}; I have a couple of observations. I believe the call to So I guess your When I ran the code using the command
I found the same behavior i.e., the test doesn't run to completion. So I was wondering, is the code you shared that is causing the problem rather than TestNG blocking gc by holding up references to test class objects ?
When the execution of |
You are right, the MemoryLeakTestNg instance keeps querying the counter, but that should not keep the GC from getting rid of the MyTestClassWithGlobalReferenceCounter instance ? I actually tried to run the same setup with the latest JUnit version ( just to be sure, that not this construct is causing the GC from removing our Test instance ). As expected the test exists with the following output:
Here is source code (tested with Java 1.8.0_101-b13 and JUnit 4.12 ): https://gist.github.com/kiru/b87a1d42c720966f8fe0b9b99a4bedd6
Tested with the latest stable version ( 6.11 ), memory leak is still present. |
@kiru What if you disable all reporters? |
@juherr Disabling all reporters should not be the solution, but maybe a good workaround. I am not sure how to disable all the reporters, I tried with the following changes, but had no effect.
|
testng.setUseDefaultListeners(false); should be enough. And the idea was to find the root cause. If the problem still exists without listeners/reporters, then the problem is somewhere else. |
Hello Julien, I found the reason why in this case the TestNG instance is not GC'ed. It seems that TestNG is a singleton class. It keeps the latest created instance as a reference:
Currently, that instance is only used by ExitCodeListener. To fix the above test case, I changed the run-
Nevertheless, it does not fix the actual memory leak. You mentioned that by design the reporters keep an instance of the test instance. I don't see that with the JProfiler. Thank you, |
Fix Issue #1461: TestNG not getting garbage collected
The |
@ben-manes I'm not quite familiar with the IInvokedMethodListener. Do you have any code samples? |
I'm seeing a similar issue. We use an IInvokedMethodListener and after each invocation, we write the results to a DB and then technically we are done with the TestResult. I'm seeing that org.testng.internal.MethodHelper is holding onto a bunch of records in a static field and eventually is causing an OOM. I bumped to 6.14.3 hoping the above fix would help, but it hasn't. Is there some way of getting testng to let go of these results? We basically are running a suite of tests on demand and creating a new TestNG object each time. In theory, when the suite of tests is done we should be able to clear everything. Note I do have an hprof if anyone is interested in it. |
@jeffwcook The patch for this issue did not fix the memory leak. We ended up writing a method to set all the non static fields in the tests to null after the tests were done. That way our objects were freed, but TestNG was still keeping an instance to the Test. |
That's interesting. Do you have some sample code of that? |
Most of the code is proprietary, but it looks similar to this:
The above snippet should be enhanced to add all the Fields from superclasses as well. |
You might also want to look at the sample I gave earlier doing this in an |
I'm seeing a similar issue where an object doesn't get cleared from a |
@Pr0methean try using Guava's |
Also, don’t use G1 for reference caching tests. It uses regions which are collected independently, so it might not eagerly collect soft/weak references. Use ParallelGC for predictable tests if you rely on GC behavior. |
TestNG Version
6.9.10
Expected behavior
After completing a test, we expect test object to be garbage collected.
Actual behavior
Test objects are not finalized / garbage collected => which leads to an out of memory problem when running a large test suite
Is the issue reproductible on runner?
Test case sample
Please find below a standalone main class reproducing this problem.
It shows that test objects are not garbage collected / finalized
The text was updated successfully, but these errors were encountered: