LV crashes when number of (his own) threads goes over 150.

[GuillermoP]

Hey,

I've found LV crashes when it goes over 150 threads. Is this true? I'm not particularly interested in having so many threads and have already removed the "problematic code" from my application. However, LV should return an error instead of crashing.

How to reproduce:

I'm using LV 8.6 on a dual core Dell Latitude D830, WinXP Prof sp2.

I've created a simple reentrant VI with a TimedLoop inside. The VI is programmed so it consumes minimal CPU resources and memory. The TimeLoop structure creates the threads (in my application, I've replaced them by regular While Loops and it goes fine).

Then I've created another VI that calls the reentrant VI several hundred of times.

Run it and LV crashes when it reaches the 150th iteration. From Windows Task Manager window, CPU use is around 25% and I've only used 20MB of memory, thus it looks alike to be an OS problem.

Is this a configurable parameter in LV? Can I change it? Wich is the maximum number of threads I can create in LV? Can this crash be changed by a simple Error that can be handled?

Thank you and Buenas fiestas!

Guillermo

[altenbach]

Can you clarify what you mean by "create threads"? What is your definition of a thread? Maybe attach your VIs?

Is this in any way related to the following note:  How Many Threads Does LabVIEW Allocate?

[GuillermoP]

Hi,

You can find the total number of Threads (not just the LabVIEW ones) into the Windows Task Manager (right click on the task bar >> Task Manager).

Place the attached example VIs (LV 8.6 and LV 8.2) on the same directory. Run "master.vi" and you'll see the number of threads grows with the automatically opened reentrant VIs. When new created threads go beyond 150 (around the 130th FOR loop iteration), LabVIEW suddenly crashes and hangs.

Hope this helps better understand the problem.

Thanks!

Guillermo

[Jarrod_S. · Accepted solution]

This isn't so much directly related to the total number of threads LabVIEW is using being 150. The issue is most likely that LabVIEW has a limit of 128 timed loops running at a time. I believe you are reaching this limit and LabVIEW is not behaving as desired. This link has this quote about what LabVIEW should do in case you exceed this max:

"The Output node returns error information received in the Error input of the Input node, error information generated by the structure during execution, and error information from the subdiagram that executes within the Timed Loop. For example, if an external source aborts the execution of the Timed Loop or if more than 128 Timed Loops run at one time, the Output node returns an error. The Output node also returns timing and status information for the loop."

[altenbach]

Jarrod,

Your link is malformed. Could you try to give the correct link once more? (Or ask Laura to correct it).

[Jarrod_S.]

Yikes, not sure how that happened. Thanks for the heads up. Here's the real link.

[GuillermoP]

Congratulations for finding the root of the problem.

However, I've added an Error global variable in order to confirm your quoted text and thus avoid having LV crashed. Results are not satisfactory since LV continues to crash but Error never appears into the Global.

Maybe I'm doing something wrong and Error should be detected -and avoided afterwards- by means of different programming?

In any case, in my humble opinion, LV should not crash for this reason, and if yes, at least better explain why it does. Don't you agree with?

Find attached an image of the writen above and the error details.

Thanks and regards,

Guillermo