teststand handles accumulate

[JMH]

I am having a problem with teststand/testexec accumulating handles. I am running Teststand 3.0 and LabWindows 7.0 using TestExec to control Teststand.

I load my test program (.seq) into testexec and look at the handle count using task manager. I execute my program and when it finishes I can see that the handle count is higher than it started. I run again and it increments again. I have a need to run this test program at least 200 times but I receive an error message from fopen (errno) that the maximum number of files are already open. I have fixed some issues in my program but I think there are issues with TestStand as well.

If I run one of the example testexecs shipped with Teststand and use an example sequence file such as Benchmarks.seq ( I don't have LabView so I click continue without labview) I see the same thing happening, the handles increment.

Any suggestions?


JMH
MTI

[Andrew W]

Howdy JMH -

I see the handle increase happen, but when I close the execution in the Operator Interface, the handle count drops again.  Are you leaving the executions open in the Operator Interface?

Also, I am not familiar to the fopen error you are referring to.   Are you seeing this error in the Benchmarks.seq as well?

I look forward to your responses.

Regards,
Andrew W
National Instruments

[JMH]

Hi Andrew,
I do not close executions. I am running in an obj module called by the Testexec and I run the sequence file programmatically. The executions act as a history of the testing process as each one has a report associated with it.
However, I did look at the sample testexec using benchmarks.seq and it does release some handles when you close the execution but not all and if you continue it will accumulate the handles. My latest run for benchmark showed:
start 473
finish 524
close exec. 511
start 511
finish 533
close exec. 515
start 515
finish 539
close exec. 521

I am not seeing the fopen error in benchmarks.seq. It is in my program. It just happen to be the first call trying to acquire a handle after all of the handles have been allocated. Using my testexec and test program I received the error after I (testexec, teststand etc.) had over 3000 handles allocated.

Thanks for your response,
John Hopkins
MTI

---

@Andrew W wrote:
Howdy JMH -

I see the handle increase happen, but when I close the execution in the Operator Interface, the handle count drops again.  Are you leaving the executions open in the Operator Interface?

Also, I am not familiar to the fopen error you are referring to.   Are you seeing this error in the Benchmarks.seq as well?

I look forward to your responses.

Regards,
Andrew W
National Instruments

---

[JMH]

Andrew,
Were you able to duplicate the problem of handles accumulating using the simple testexec and benchmarks.seq?

John

[Josh_W]

John,

Andrew has moved out of the department since the last time you corresponded with him, so I will be taking over this issue.

I looped benchmarks.seq for an entire hour today, and only saw the number of handles increase by 200, and after I closed the window, the number of handles dropped by 70.

I looked up the fopen error that you were getting, and it looks like the function 'fopen' is part of the ANSI C library used for opening files.  My guess is that some files you are using are not getting closed correctly, and so fopen is giving an error that it has the maximum number of files open.

Let me know if this doesn't help, and we'll try to troubleshoot from there.

Josh W. | National Instruments | Applications Engineering

[JMH]

Josh,
Thanks for your reply.

If I understand your response you are saying that Testand is accumlating handles. Why? Shouldn't it release them after use? I don't understand what window you are closing. If I close everything but the simple TestExec I still have more handles allocated than I started with. Fopen is not an issue at this point as I am reporting the accumulating handles just using the simple NI TestExec and BenchMarks.seq.

John

[Josh_W]

John,

I've sent the issue up to R&D for further evalution, because we are seeing some of the same behavior here.

I guess I've lost track of your original issue through all this.  If you could refresh my memory, I'll try to get it resolved.

Josh W. | National Instruments | Applications Engineering

[JMH]

Josh,
We run a TestExec/Testand (written in CVI) application which executes test programs (.seq files). On occasion the signature based utilities such as Collect and Fault Insertion run the test program many times. I noticed that we would reach a certain point then gpf. I started looking at handles because of a message I received when trying to do an fopen. I fixed the handle problem in our app. but still noticed that the handles incremented, so I tested by running the simple NI Testexec and benchmarks.seq and found that on my system the handles were accumulating. I have tried unloading the executions and even tried "unload all Modules" but these didn't get rid of the problem, plus I would like to keep the executions so the operator can see a history of what he has done.

John

[Josh_W]

John,

We will have R&D take a look at the behavior of handles as TestStand runs.

However, I'm still a little unclear about the issue that caused this discussion.  What faulty behaivor are you now seeing with your program?  Are you still getting GPFs?

Josh W. | National Instruments | Applications Engineering

[JMH]

Josh,
There at least three issues here. First our application could only run 24 -25 times before it crash. I located a couple of memory problems (mallocs with no frees) which I fixed. I then could run more times but it would crash after 120 iterations with no real information. I then looked at the errno variable set by fopen and found that I was running out of handles (our tester uses a lot of devices). I was able to find some issues in the program but I was still running out of handles. Then I tested using the simple TestExec and Benchmarks.seq and found that that setup was also accumulating handles.

John