Teststand 3.5 Memory Leak Strategies

[rw1dale]

I am experiencing a memory leak when running my test seqeunce using TestStand 3.5.  I have read several messages and Knowledgebase entries to try and collect intelligent memory leak strategies.  I have been running Perfmon on my Windows XP PXI controller card to collect data on the Private Bytes for the process SeqEdit.  This shows a memory increase with each test cycle of over 500 KBytes.  I am trying to reduce my huge test sequence file down to determine where the leaks are occuring, but have the following questions in order to more fully understand TestStand memory issues:

1) I understand each individual step in a sequence can record results if not disabled.  So, if there are thousands of individual steps this could take up quite a lot of memory.  Does TestStand allocate new memory for these step results, or do the results get stored into memory already allocated for TestStand when it is invoked?  By the way, I debug the memory leak issues with reporting disabled.

2) If the step results are stored in newly allocated memory, at what point does TestStand free up the additional memory it allocated for the step results?  Is it inside the process model?

3) Is there a way in the sequence editor to turn off Record Results for multiple steps at once, or must they all be turned off individually (soooo time consuming!).

4) If memory is newly allocated, is there a step I can execute to force memory to be freed up?

Ideally, I should be able to start at a certain memory level, execute one test cycle (which has many memory allocations and de-allocations), and at the start of the second test cycle be at the same memory level that was present at the start of the first test cycle.  I actually focus my attention on the second test cycle vs. the third, fourth, ... since the first test cycle can load DLLs for the first time and will affect memory size.

Any information on the above questions will be greatly appreciated.

Ron

[CorbinH]

Hi rwdale,

 TestStand allocates new memory for each step result dynamically. This means for each new entry in the result list new memory is allocated for that steps results. The way TestStand frees up the memory used for the results depends on what report options you have selected. By default the memory allocated for results is freed after the sequence is executed. This means after each UUT you test, the results are dumped into the report and the memory is freed. If you select On-The-Fly reporting the results are dumped into the results file after each step.

As far as turning off Record Results for multiple steps at a time, I don't believe you can in TestStand 3.5. That is something that you can do in TestStand 4.1 though.

[rw1dale]

Corbin,

     Thanks for the reply.  Can you expand on "By default the memory allocated for results is freed after the sequence is executed."  For example, where does the memory get freed up.  Probably inside the process model somewhere.  I have report generation disabled during my memory leak debug, so there should not be an output of results to a file.  TestStand will still collect step results but has to discard the results at some point.  I want to know where that happens.

Thanks,

Ron

[CorbinH]

Ron,

What I meant by "default" was just when report generation is turned on and On-The-Fly Reporting is off. The memory used by the results array is released once the scope of the results is lost. In other words, when your sequence is done and ends, the memory is freed. When you use Test UUTs instead of Single Pass, the memory is not freed until the testing is "stopped" instead of choosing to test the next UUT. This does not mean that more and more memory is used for each pass. If you look at the process model for Test UUTs entry point, there are a few steps that clear the results container. That means the memory is still allocated, it just gets cleared and replaced with the new results.

You keep referring to this as a "memory leak" when it actually is more along the lines of just getting more and more values to be stored into memory instead of a "leak." Something you might check to see is if you are storing numbers in huge arrays, which will also take large chunks of memory. You shouldn't be seeing a memory problem with just a couple thousand steps. I have seen sequence files with over 10,000 steps run before. One other thing you might consider is if you use On-The-Fly Reporting, you will see a slow of execution time.

[CorbinH]

If memory usage is a problem and you do not care about the results for each step, there is another option. In the Station Options dialog box, at the bottom of the execution tab you can select "disable result recording for all steps."

If you don't want to disable results for all steps, you can disable just a sub-sequence by selecting Edit » Sequence properties.

By recording results for only the steps you really care about, you will free up memory as well as see faster execution times if using On-The-Fly reporting.

[mitulatbati]

Hello,

I´m not sure, whether this topic actual, but I created a small tool, which proceeds this time consuming job to remove "record results" property for each step.