Using CloseExecution from my OI leaks memory, but using SetAutoCloseExecution doesn't. Why?

[AndrewL]

Hello,

I have a custom Operator Interface (OI) that is using a custom Process Model to call my Sequence File (which is just passing a few dummy tests at the moment). I have a pretty bad memory leak which I have narrowed down to the following:

In its original state, my custom OI runs the Single Pass entry point in my custom Process Model and retains the reference to the Execution. The execution is left open until the Operator hits the Run button again to kick off the next execution, at which point the OI closes the last Execution by calling ApplicationMgr.CloseExecution and then passes the last Execution reference to the Close Reference VI. With this method the LabVIEW process in the Windows Task Manager gains ~1.5MB every dozen DUT runs.

I changed the way my OI closes the Execution and the Execution reference. After calling Run on the Single Pass entry point, I made the OI call ApplicaionMgr.SetAutoCloseExecution on the Execution reference and then close that Execution reference straight away. This results in the memory leakage dropping to ~50KB every dozen runs.


Does anybody know why this change results in such a large difference in memory usage?
I have explored other possibilities such as clearing Locals.ResultList in the process model, but none of these seemed to make an impact. I need to understand this because the 'improved' version of my OI also displays the unfortunate behaviour of clearing the OI's display of the Execution's Report when the Execution automatically closes/disappears!

TIA for any advice!

[Adam B.]

Andrew,

I just wanted to get a little more information from you in regards to the memory leak you are experiencing. What version of TestStand are you using? Are you generating reports using the ASCII, HTML, or XML options? Have you tried running the OI with the NI default process model, or even the NI OI with your process model to ensure which component is creating this behavior? Finally, I'm not sure what you mean by "I need to understand this because the 'improved' version of my OI also displays the unfortunate behaviour of clearing the OI's display of the Execution's Report when the Execution automatically closes/disappears!". Are you using the CloseExecution or the SetAutoCloseExecution in this case? Any additional information you can provide would help here. Thanks a bunch and have a good one.

Adam B.
Applications Engineer
National Instruments

[AndrewL]

Hi Adam,

I'm using TestStand 3.0 and am using ASCII report generation.

Using an NI OI with my process model results in no memory leak.
Using my OI with my process model stripped of all steps except for the posting of UI messages back to the OI and the MainSequence callback still results in the memory leak. If I go a bit further and skip the MainSequence callback then the leak disappears.

The original version of my OI used CloseExecution, but only called it just before starting the next Execution. This enabled the ReportView control to display the Execution's report on screen until the operator wanted to begin another execution. However, memory leaked badly.
The modified version of my OI uses calls SetAutoCloseExecution immediately after making the Execution run. Hence, no call is made to CloseExecution here. But what happens when using SetAutoCloseExecution is that when the Execution closes when the run is finished (as desired), the ReportView control gets cleared at the same time as it had a connection to the ExecutionViewMgr (not desired). This is annoying because the operator can't view the report for that Execution as it disappears too quickly. However, memory doesn't leak (well, it's much much slower) this way.


I tried a few things, such as clearing Locals.ResultList at the end of each run, but changing from CloseExecution to SetAutoCloseExecution was the best remedy for the memory leak.

Thanks for your help!

[Adam B.]

Andrew,

Would you willing to post your OI? I would like to look into why it might be causing the memory leak. I'm wondering if somehow the executions are somehow not getting closed properly, as I've seen this be the the cause of a couple of memory leaks in the past. It doesn't appear that this has anything to do with your custom process model, so I don't think it would be necessary to include this file as well.

As far as your work around of using SetAutoCloseExecution and having the report close too quickly, you could always use an external viewer. This would open the report in say, Internet Explorer, and then it really wouldn't matter that the execution gets closed right away. However, I would still consider this a workaround due to the fact that this runs slower and frankly you should be able to view the report in your OI.

I would love to take a look at what is going on in your code so that we can get this working for you in the desired manner. If you don't wish to share this so publicly, we could also do it through email. Let me know. Thanks a bunch.

Adam B.
Applications Engineer
National Instruments

[AndrewL]

Hi Adam,

That's fine. I've attached the top level VI that makes my OI. Obviously it won't run since I would have to send you about 7MB of other files with that go with it. But you should at least be able to look around and figure out what's going on.

Regarding the Execution not getting closed properly, that's what I reckon. Although, I did try checking the boolean output of CloseExecution() to see if it reports closure, and claimed that it was closing it. *shrug*

The external file viewer is exactly the route I've taken for my workaround. This has another benefit in that the ReportView control's print feature was disfunctional. I would press Print after being shown the Print dialog, but nothing ever reached the printer. So, we had to make our operators use an external application (notepad) to print these anyway. As for the workaround making it slower, there is absolutely no noticable difference. Actually, since there's no memory leak performance is waaaaay better.

The attached version is the one that uses CloseExecution and leaks (a lot).

Thanks!

Message Edited by AndrewL on 03-15-2005 06:22 PM

[Adam B.]

Ha Ha, oops. I guess I need to read my posts more carefully. I read this line "However, memory doesn't leak (well, it's much much slower) this way." and assumed that you meant that things were running slower. In hindsight, I certainly see that you mean that the memory is leaking much slower which makes a lot more sense. Sorry about the confusion. I'm now taking a look at your operator interface and will let you know if I see anything that explains this memory leak.

Adam B.

[Adam B.]

Andrew,

Just a thought, but have you tried running the ApplicationMgr.CloseAllExecutions method as opposed to the CloseExecution method. This would allow you to view the report in your OI as you were desiring, but should ensure that all executions are closed before starting the next execution. However, I've still yet to find what might be happening in your current OI architecture that would not allow you to achieve this as is. That's why I'm curious to see whether closing all executions will also give you a memory leak. Please try changing your CloseExecution to a CloseAllExecutions and let me know the behavior that you see so we can further narrow this thing down. Thanks a bunch.

Adam B.
Applications Engineer
National Instruments

[AndrewL]

Hi Adam,

I just tried replacing the call to CloseExecution with CloseAllExecutions, but unfortunately it didn't make the memory leak go away.

For now, I have just settled on using SetAutoCloseExecution and not having the report display in the OI after the run.

Thx!