Running out of threads

[Matthew_Kelton]

I have built a sequence to perform a long-term test using TestStand 4.0 and LabVIEW 8.2.1.  The test continuously communicates with the UUT to detremine its status.  About 70 hours into the test, I received a TestStand error stating that I had run out of threads.  I do not use multithreading in my sequence calls, so I am assuming that it is an issue in calling the LabVIEW VIs and threads not being disposed of properly.  The error occured within a VI using the sequence context, so I am wondering if that is creating the threads, and I am not properly handling the context somewhere causing the thread to no be closed.

Any ideas?

Thanks,
Matthew

[Matthew_Kelton]

Forgot to add the error code is -2147024732.

[AndrewMc]

Hey Matthew,

I'm not sure why this is occurring.  One thing that you can look at is using Process Explorer (Sysinternals) to view the threads for the process.  If you look at the threads, perhaps you might notice a trend of multiple threads continually be created.

[Matthew_Kelton]

Andy,

Thank you for the suggestion.  I downloaded the tool and found I had no thread problems as far as the OS was concerned.  I was able to play with the code once I got back to the error state and found that I could rerun the VI and it would error sometimes and work others, and it always failed at a TestStand API call to create a subproperty or an AsPropertyObject.

I decided it was probably a Vista issue.  I had installed TestStand and later found that it wasn't Vista compatible.  SInce I had only run into GUI issues and crashes, I assumed that was the bulk of it.  And since I didn't have time to reset the computer, I figured I would deal with the problems until this project was complete.

I decided to invest the time and went back to XP, and ran the enitre test without problems.

So, it appears this is one of those Vista incompatibilities.  Serves me right for not reading the realse notes.

Matthew

[david_jenkinson]

We've been having this problem off and on, just had it again.  We run long duration tests, >24 hrs frequently.  When we have the error, it is pointing to "get property value (string).vi" in one of our vi's, which is in a loop and constantly reads this property for much of the test.  I believe I have a separate thread on this somewhere but I decided to post here because this sounds like our problem exactly.  We are using LV 2011 SP1 (32 bit), on a windows 7 64 bit os.  Any insight?  We get it rarely any more, but it just happened again and does screw our test up.

Thanks

David J.

[MinXu]

We have similar issues with Test Stand 2014 and Labview 2014.  Latest is with one of the high end Lab PCs, the test has been ran for more than 12 hours.  It ran out of thread in the middle of the sweep.  Station still reports having more than 11G of RAM out of 16G of RAM available, both test stand and labview consumes reasonable amount of memory, does not look like a memory leak.  There are 16xx thread running compare with a freshly booted PC without test stand and labview running of 14xx threads. 

Once this error happens, you cannot do any operations in test stand, even save the file.  Since Test Stand does not have a thread limit, I have been looking at Microsoft website for thread issue, most direct to VM Manager (error 2912).  The fix is stop and re-start the service.  Manually tried that, but once these settings comes into effect, it want to reboot.  

Anyone else have a good suggestions beside breaking down the test, make the test run shorter, before the limit hit?

[dug9000]

While you are running your sequence, if you look at the number of threads used by teststand and by labview, is one or the other of those steadily climbing? For example, if you let it run for 10 minutes, check the number of threads, and then let it run for ten minutes and check the number of threads is the number of threads in one of the processes continually climbing?

-Doug

[MinXuM]

The answer is no.   I have been monitoring a station for a few hours, the thread and handles count in the system will cycle up and down, nothing out of ordinary.  When the running out thread error happens, I do not see any abnormalies.  Here is some windows statistics.

Below is the PC health when thread error ocurred.

Below is when the PC is just been rebooted.

Below is when the sequence is running.  

[dug9000]

I recommend looking at the per-process number of threads in the process list (you can add a column for it if needed), and see if that number is steadily going up in either TestStand or LabVIEW. Also what is the exact error message you are getting. Perhaps a screenshot of the error dialog if possible.