terminate an execution

[Angel Olivares]

Hi,
I'm having a lot of problems due to memory leak. I still haven't found the root cause. Anyway, this is not a real problem if I can automatically terminate the execution (the memory will be released) and restart the execution again. I can terminate the execution with the TestStand API without problem, but then the execution is stopped and I cannot restart it again. I've tried to execute the Restart command from the API in the middle of an execution but it doesn't work. Is it possible to do this? Has somebody an example?
Thanks,

Angel

[Scott_Richardson]

Angel -
In general when memory leaks occur within a single process, the process must end in order for the memory to be returned to the OS. When TestStand terminates an execution, TestStand does nothing to "release" the memory back to the OS.

The Restart API method only applies to an execution that has completed. It will not work on an execution that is running.

The only reason why an execution cannot restart is if when it was created, the "executionTypeMaskParam" parameter of the "Engine.NewExecution" method specified the "ExecTypeMask_NotRestartable" constant.

How are you determining that you have a memory leak and is it for the TestStand process?

[Angel Olivares]

Hi Scott,
could you have a look at his thread: http://forums.ni.com/ni/board/message?board.id=330&message.id=5902#M5902

I have posted some questions explaining this thema. There you will find my real problem. Bye the way, I send you a small example. I'm using this VI in the PostStepFailure StationCallbacks.seq and I think I'm not sure if I have to close the reference. Normally I close it always when I use an Open Reference vi, but as I've taken the property object directly from the sequence context I haven't done it. Could you please correct it and resend me if it's failed? Thank you very much!

Angel

[Scott_Richardson]

Angel -
When you are given an object as a parameter, the object already has a reference, so you do not need to close the reference. The caller is responsible to release the reference.

If you call a method that returns a different object, the method returns the object with a reference and must be explicitly released using a Close Reference VI.

If you wire a reference thru a VI, the above rules do not change.

LabVIEW does keep track of additional references added to objects while running the VI. Since you are calling the VI using TestStand, LabVIEW does cleanup these references when the VI is unreserved. By default TestStand unreserves the VI when the execution is complete. This would explain why you see the leak cleaned up when the execution goes away.

[Angel Olivares]

Hi Scott,
What does it mean that the VI is unreserved? Can only TestStand "unreserve" the VI after the execution completes? How can I avoid it?
Running the SequentialModel from NI and one of the examples with LV code written by NI I didn`t found memory leak, so the problem must be in my SW.
Regards,

Angel

[Scott_Richardson]

Angel -
There are settings on a step and its sequence file that instruct how adapters are supposed to load and unload code modules. For example, when the C/C++ adapter loads the code module for a step, it loads and unloads the DLL from memory. For the LabVIEW adapter, it instructs the LabVIEW developement environment or the run-time to load and unload the VI from memory. Because LabVIEW handles references to files, hardware, etc, it must know when to release these references if a VI fails to do it. Most LabVIEW users understand that LabVIEW auto-closes these references when their executable is no longer running. TestStand is not a LabVIEW executable, so TestStand has to communicate when "execution of the VI" is complete. In the adapter configuration dialog box for LabVIEW, there is an option to "Reserve Loaded VIs for Execution". I recommend looking at the help for this option. LabVIEW considers that a VI is running in an executable, while TestStand has it reserved. As I mentioned, looking at the VI that you previously attached, it was failing to properly release an ActiveX reference. Yes you could uncheck this adapter option and your memory leak will probably not occur, but you have code that is not written correctly and this should really be fixed.