LabVIEW
Data type parsing VI "Get LabVIEW Class Parent and Member VI Information" used repeatedly can crash LabVIEW
While trying to answer to this thread, I started playing around with LV classes, interfaces and variants.
Sporadically when benchmarking my code, I had LV crash with the following log:
"e:\builds\penguin\labview\branches\2020\dev\source\linker\CloseOperation.cpp(1585) : DAbort 0xA967C488: The close operation should only ever execute in the UI thread."
I finally managed to narrow down the issue to the VI "Get LabVIEW Class Parent and Member VI Information" from the Data Type Parsing palette. When called repeatedly in a loop, it seems this VI can crash LabVIEW:
I could make LV2020-32bit, LV2021-32bit and -64bit, LV2022-32bit and LV2023-64bit crash, on my computer and that of my colleague.
I managed to make a minimal project and a procedure that should provoke the crash:
1. Unzip the folder;
2. Open the lvproj with any LV version;
3. Open "Main.vi", show its diagram;
4. "Run continuously" for 4-5s;
5. Clear full compiled object cache (Tools > Advanced > Clear Object Compiled Cache... > Select All > Clear);
6. "Run continuously" again for 4-5s. Here it should crash;
7. If it doesn't, try "Save All" (Ctrl+Shift+S), then go back to step 4. It is sometimes quite hard to provoke.
Regards,
Raphaël.
Hello Raphael,
Thanks for the VI attached and for the steps to reproduce the issue.
I noticed that instead of pressing "Run Continuously" button if I increase the number of iterations to 4000-5000, I receive the same error. It looks like this.
But if we place a simple wait function and make each iteration run for example during 0.001 seconds it works without any error. So, in my opinion, this is not a bug, but a resource management issue in LabVIEW.
When you run a loop with a high number of iterations without any delay, LabVIEW might be overwhelming the CPU or memory resources, leading to a crash. Without a delay, the loop runs as fast as possible, consuming a lot of CPU resources. This can cause the system to become unresponsive or crash. Adding a small delay reduces the CPU load, allowing other processes to run smoothly. Rapid execution of the loop can lead to excessive memory usage, especially if the function inside the loop allocates memory.
By adding a small wait time, you’re essentially giving the system a breather, which helps in maintaining stability and preventing crashes.
Hello Mr.Genius,
Thanks for the technical explanation, and I am always glad to see NI employees answer on the forum.
@Mr.Genius wrote:
So, in my opinion, this is not a bug, but a resource management issue in LabVIEW.
I don't know your definition of a bug, but from the user point of view, an application that crashes is always considered as a bug. Also, if for technical reasons the root cause cannot be fixed, that application should not allow the user to go in a path that leads to that crash.
@Mr.Genius wrote:By adding a small wait time, you’re essentially giving the system a breather, which helps in maintaining stability and preventing crashes.
This is not an acceptable fix, what if my machine is slower or is an RT target? What if that fixed delay of 1ms is not sufficient? This also suggests that this is a broader issue than just a bug in a particular VI. I feel like this could happen anytime I manipulate classes and variants in a way that pushes the CPU a bit too much.
Even with the added delay, imagine a generic plugin-based architecture that loads lots of classes at runtime. This is silly to freeze the application for 1ms for each object instance because of this exact VI while all other Data Type parsing VIs are perfectly fine and fast.
Whatever happens on the "resource management" level of LabVIEW, there should be locks to prevent that crash from happening.
Regards,
Raphaël.
- last edited on by
NI_Community_Su
Definitely a bug Mr, Genius.
Your “solution” is at best a workaround, which might or might not always work, but definitely not a real solution.
Make that bug report!
