Exception when making snapshot from dotMemoryUnit
We run our SpecFlow tests using a separate MSBuild definition. This build will 1) start dotMemoryUnit, 2) run vstest.console.exe 3) start SpecFlow framework 4) run all SpecFlow unit tests (SpecFlow tests are compiled to unit tests).
We see the %USERDATA%\Temp folder running full. After a few hours, we see about 70GB of data parked in the temp folder. This only happens when dotMemoryUnit is wrapping the normal SpecFlow test runner.
In our execution output, we see a lot of errors like:
1>EXEC : warning Message: [d:\{PathOfMsBuildFile}]
The previous error was converted to a warning because the task was called with ContinueOnError=true.
Class Initialization method {NameOfUnitTestClass} threw exception. JetBrains.Profiler.Windows.Api.ProfilingApiException: JetBrains.Profiler.Windows.Api.
ProfilingApiException: Unrecoverable error.
Stack Trace:
at JetBrains.Profiler.Windows.Api.Impl.Helper.CheckHResult(HResults hr)
at JetBrains.Profiler.Windows.Api.MemoryProfiler.Dump()
at {NameOfTestClassManagerMakingASnapShot}(String title) in {PathOfTestClassManagerMakingASnapShot}.cs:line 39
I suspect these errors come from a full disk. For some reason, dotMemoryUnit overflows the temp folder. Our class is annotated with
Snippet
[DotMemoryUnit(FailIfRunWithoutSupport = false, SavingStrategy = SavingStrategy.Never)]
So it looks like I have configured it properly. The docs say the following:
The default dotMemory Unit configuration allows using it “out of the box”. Nevertheless, in some cases you may want to redefine particular options like workspace files location or total size limit for auto-saved workspaces. This is done with the help of DotMemoryUnitAttribute placed before an assembly, a test class, or a test method.
The class which is annotated with [DotMemoryUnit ...] attribute is *not* located in the assembly where the unit tests are located. However, this class *does* call the DotMemoryUnitController.TestStart() and DotMemoryUnitController.TestEnd() methods.
On what assembly must the [DotMemoryUnit] attribute be placed? Assembly containing unit tests or assembly calling TestStart/TestEnd methods?
If attribute must be placed on assembly calling TestStart/TestEnd methods, what may cause exception, and what causes excessive datadump in temp folder?
Please sign in to leave a comment.
Hi,
thanks for your feedback.
At first we need to know what kind of files takes the disk space, are they *.dmw files or some other kind?
What about DotMemoryUnitAttribute there is two options
1. DotMemoryUnitController.TestStart takes a parameter of MethodBase type, pass there a method of the type marked with DotMemoryUnitAttribute. Look at this help topic to see what I mean https://www.jetbrains.com/help/dotmemory-unit/2.3/Working_with_Unsupported_Unit_Testing_Frameworks.html
2. Apply DotMemoryUnitAttribute to a test method/class/assembly, dotMemory Unit will find such attribute automatically.
You can check if dotMemory Unit found the attribute by setting FailIfRunWithoutSupport to false and running tests w/o dotMemory Unit and see if they fail with DotMemoryUnitException or not.
Do not hesitate to ask if you have any questions.
My temp folder fills up. I get 50GB of temp files. The files taking up disk space are patterned:
They are sized from less then 1K to about 132MB. dotMemoryUnit produces this, as this does not happen without dotMemoryUnit support runs.
On a certain point (I highly suspect before I'm out of disk space) I only get exceptions like:
-----------------
DotMemoryUnitException: DotMemoryUnitException: exception occured
Inner exception
JetBrains.Profiler.Windows.Api.ProfilingApiException: Unrecoverable error
at JetBrains.Profiler.Windows.Api.Impl.Helper.CheckHResult(HResults hr)
at JetBrains.Profiler.Windows.Api.MemoryProfiler.Dump()
at JetBrains.dotMemoryUnit.ClientController.DotMemoryUnitClient.GetSnapshotInternal()
at JetBrains.dotMemoryUnit.ClientController.DotMemoryUnitClient.GetSnapshot()
Stack Trace:
at JetBrains.dotMemoryUnit.Client.ReflectionExtension.Invoke[T](Object instance, MethodBase method, Object[
] args)
at JetBrains.dotMemoryUnit.Client.DotMemoryUnitProxy.GetSnapshotInternal()
at JetBrains.dotMemoryUnit.Client.DotMemoryUnitProxy.GetSnapshot()
at JetBrains.dotMemoryUnit.Kernel.dotMemoryApi.GetSnapshot()
at JetBrains.dotMemoryUnit.dotMemory.Check()
[removed our code]
---------------
I suspect dotMemoryUnit simply has no disk space to its thing.
However, I also see exception traces like
---------------------------
DotMemoryUnitException: DotMemoryUnitException: exception occured
Inner exception
System.NullReferenceException: Object reference not set to an instance of an object.
at JetBrains.dotMemoryUnit.ClientController.DotMemoryUnitClient.EnsureTestExecutionEnvironmentIsSet(KeyValu
ePair`2[] oneStepKnownMethods)
at JetBrains.dotMemoryUnit.ClientController.DotMemoryUnitClient.GetSnapshot()
Stack Trace:
at JetBrains.dotMemoryUnit.Client.ReflectionExtension.Invoke[T](Object instance, MethodBase method, Object[
] args)
at JetBrains.dotMemoryUnit.Client.DotMemoryUnitProxy.GetSnapshotInternal()
at JetBrains.dotMemoryUnit.Client.DotMemoryUnitProxy.GetSnapshot()
at JetBrains.dotMemoryUnit.dotMemory.Check(Action`1 check)
----------------------
Maybe some snapshots go bad, then the temp files are not cleaned up. Could this be the case?
Hi,
these files are temporary snaphsots data generated by dotMemory Unit, you are right. It looks like a bug, normally they should be deleted just on finishing of each test. We will investigate the problem, thank you for report.
May be it will disappear if you pass right MethodBase into DotMemoryUnitController.TestStart().
I will write here once we found a reason of bug and/or workaround for you.
Ed,
Any progress on your side so far? We're blocked introducing automated memory leak tests. Thanks in advance!
We will fix this bug in the nearest release. Sorry for inconvenience.
Have you checked that dotMemory Unit find appropriate DotMemoryUnitAttribute BTW? Have you tried to pass correct MethodBase into DotMemoryUnitController.TestStart method?