chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.
0 votes
Recently our unit tests have been running out of memory. Investigations showed that the managed heaps were all ok, and it was unmanaged memory that was leaking. Looking closer, it seems that the majority of this is the assemblies that get created by Isolator when mocking interfaces and other objects.

We have many tests that mock interfaces, and in a large fixture the same interface may be mocked many times. Apparently Isolator builds and loads a new assembly for the same mocked interface everytime the type is mocked. In some cases this has resulted in hundreds of assemblies for just one interface.

This is now causing serious problems for us as our unit tests and nightly builds are regularly running out of memory. Is there any way to stop the creation of so many assemblies, and make Isolator reuse the same assembly for the same mocked type?
asked by timberston (1.3k points)

6 Answers

0 votes
Thank you for informing.
We will investigate the problem and will be in touch.

Menahem Cohen
answered by Menahem (260 points)
0 votes
I thought perhaps some more info on reproducing the issue would help.

Take the following NUnit test code.

[Test]
public void MakeMemoryLeak()
{
for (int i = 0; i < 1000; i++)
{
MockManager.Init();
MockManager.MockObject(typeof(IList), Constructor.Mocked);
MockManager.Verify();
}
}

Now, before running the test, go into Perfmon and add the following counters.

.NET CLR Loading -> Bytes in Loader Heap
.NET CLR Loading -> Current Assemblies

Note that when the test is run, the # of assemblies loaded quickly rises to over the 1000 mark, and the total bytes in the loader heap also rises as the assemblies are loaded.

Is there a way to stop this? Can the interface mock be created before MockManager.Init, which would allow us to use a single instance for all our mocking?
answered by timberston (1.3k points)
0 votes
Hi Tim,

That's exactly how I reproduced that. Only I stopped at 100 :)
There's no current work around, if it's all in one assembly. If it's not, you can run separate batches, and when the process exits, the memory is freed.

We're working on a fix right now. We'll keep you posted on our progress.

Thanks for the info,
answered by gilz (14.5k points)
0 votes
Hi Tim,

We've created a patch that solves this issue. However, I have a problem with sending you an email - I get an error about the email you registered with.

Please send an email to our Support email (support at typemock dot com) and we'll gladly send you that patch.

Thanks,
answered by gilz (14.5k points)
0 votes
Thanks for the patch. Memory consumption now peaks at about 400MB (instead of 1.3GB), and there is a reasonable improvement in run times.

Thanks very much for your quick response. We are nearing a release, and the last thing you want is an unreliable build process when you have a deadline.

Thanks again.
answered by timberston (1.3k points)
0 votes
Tim,

Glad to be of help. :lol:
answered by gilz (14.5k points)
...