LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

teststand memory leak

Hello,

 

I have browsed through the forum, and found a lot of similar problems, but no solution to my one.

 

I built some dlls in LabVIEW, which will be called in TestStand. I experience an extreme growth of used memory by Teststand, if I run my sequence for one week or longer. So I started the sequence in SeqEditor, and opened the windows task manager parallel. Then I ran the sequence step by step to find, which step increases the used memory. These steps are my dlls, there are two different cases:

 

1.) My dll reads data from a NI DAQ device, and passes only the mean values of some waveforms in a TestStand array. If I read only one waveforms, this means only one element in the TestStand array. I do it programatically with the "Set TestStand Property.vi" After running this step, the used memory by TestStand increases by 64kbyte. Why? I move a vast amount of data and I process it in the dll, but it should not increase the used memory of teststand. I can abort the execution, the used memory keeps its value, until I manually colse the sequence file.I tried to disable that part in my VI, where the values are written to teststand, but the memory keeps growing.

 

2. My dll doesn´t change anything in TestStand, tough the used memory by teststand grows.

 

 

- I use TS 3.1 and LV2010

- I don´t use any TestStand Model or Reporting. I save my logs programatically in one of my dlls.

- I removed the "record results" property on all the steps in my sequence

- For all the test steps are set: "preload before execution begins", and "Unload when sequence file is closed"

- I tried to change all the possible unload options, this doesn´t help. So it is not the problem of loading or unloading the step/module

 

Unfortunately I can´t provide my sources, but if anybody needs some inputs for a solution, I can answer. Thank you in advance.

 

Mitulatbati

 

0 Kudos
Message 1 of 8
(3,719 Views)

Does your LabVIEW code (dll) contain an array?

Are you changing the size of the array during run-time (ie: inserting into array)?

Did you initialize the array to a certain size? or are you simply adding to the array?

 

Do you close all the references (ie DAQmx)?  Do you open (& close) references multiple time throughout the code?

 

I suspect the issue is in the LabVIEW code, not TestStand.

0 Kudos
Message 2 of 8
(3,705 Views)

Hello Ray,

 

thanks for your reply.

 

yes, I have some arrays in my dll (only used by LabVIEW), and in addition, I set the size of a TestStand array programatically. I don't initialize my array to a certain size, because it will be determined during run time, how many elements it will have.I am opening log files too, but I close them each time correctly. So there is no waste from the logfiles in the memory.

 

I am sure I am closing all the references, which are opened. Should I close the SequenceContext reference too? DAQmx I don´t close, because it will be started once when I start the test, and it runs during the whole test - this can be 1000 functional tests.

 

Should I initialize an array, which is large enough to hold all possible data?

0 Kudos
Message 3 of 8
(3,702 Views)

My suspicion is the array within the LabVIEW code.

 

What happens is that if you do not have a pre-initialized array, LabVIEW will assign a small memory block for you array.  Each time you append to the array, LabVIEW allocates new memory for the new array, copies the contents of the old array into the new and appends the new element(s).  This gets time consuming as the array grows bigger and LabVIEW allocates larger and larger memory segments to accommodate the addition of new elements.  I do not know how well garbage collection (memory de-allocation) occurs. 

 

However, you can allocate a large memory block by initializing the array and writing into that existing array.  Since you know the index value, you can estimate if you need more memory.  You can then initialize a much bigger array, and copy the contents of your original array.  You may find that the sw runs a  little faster. 

 

What you could do is patiently run a full test (with memory leaks and all) and at the end determine the size of the array.  Initialize your array to a value slightly larger than that value.  Maybe even twice the size if memory is not an issue.  See if that resolves your issue.

0 Kudos
Message 4 of 8
(3,697 Views)

I don´t have so large arrays,  maximal 64 elements of a string array, where the strings are not longer that 10 characters.

 

I suspect more the thing with the references, I have to review my dlls, where it can come to leave a reference open.

0 Kudos
Message 5 of 8
(3,691 Views)

 


@mitulatbati wrote:

I don´t have so large arrays,  maximal 64 elements of a string array, where the strings are not longer that 10 characters.

 


 

Oh... I was not expecting such a small array.  You're correct, it is unlikely to be the culprit.

You can also post your code for review.

0 Kudos
Message 6 of 8
(3,687 Views)

A simillar memory leak was discussed in this thread.  What are the load options for the steps calling the DLL?


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 8
(3,684 Views)

I know the original post is terribly old an this reply won't help the thread opener.

But I stumbeled over it while searching the forums for memory issues and I guess the title will bring this thread up in many other searches. One possible cause was not covered in the answers yet:

The thread opener mentioned that his sequence is running for more than a week.

In such a case it is worth to check result collection issues especially if loops are used in the test sequence. Locals.ResultList (a hidden property) is usually only cleared after a UUT is finished and could grow unlimited.

See this for more info: http://www.ni.com/product-documentation/53145/en/

Message 8 of 8
(2,337 Views)