search

jmockit / jmockit1

Advanced Java library for integration testing, mocking, faking, and code coverage
Other
461 stars 239 forks source link

JUnit4TestRunnerDecorator leaking memory #159

Closed deepaksubu closed 9 years ago

deepaksubu commented 9 years ago

This is holding on to instances of mockit.internal.mockups.MockInvocation creating massive memory leaks in the process for version 1.14 of Jmockit.

deepaksubu commented 9 years ago

I was about to evangelize Jmockit at my work when this happened. I was under the impression that Jmockit does not require a test to cleanup after itself. Let me know if this was an invalid assumption from my end. I am also trying to isolate the misbehaving test on my end and I will report back my findings.

deepaksubu commented 9 years ago

So, this is not even caused by any specific test. Just introducing the JMockit dependency in a pom file causes the memory leak!

rliesenfeld commented 9 years ago

Well, I don't see any memory leak related to JMockit. Could you provide more information about the problem? What makes you think that MockInvocation objects are the cause? Did you use a memory profiling tool? Is there a stack trace?

deepaksubu commented 9 years ago

Thanks for your response. I am actually using a memory profiling tool (the eclipse one). I can see the heap increases exponentially as soon as I introduce JMockit as a dependency to one module. However, I cannot reproduce this issue outside that particular module. Need to do some more research. For the moment, I had to just remove JMockit from the list of dependencies. BTW, I still think the approach that it takes is much more superior to the other mocking tools out there.