09-22-2017 03:33 PM
During debugging of an issue, labview began crashing frequently. I started to suspect a corrupt file in the project, so I reverted to a version of the project prior to these problems and started re-introducing the changes in smaller increments, and narrowed down the problem to the re-ordering of the controls in a class definition.
The class in question is an Actor class. If I run a version of the project just before this problem started, everything executes without problems. I then open that actor’s property cluster, re-order the controls, close the property cluster and save all – that is the only change. Do Ctrl-L, and now dozens of VIs are shown as broken (but not cause of breakage listed). Close labview and re-open the project and no more broken VIs. Run the project and everything is fine, until an instance of this Actor is run, then Labview crashes. I don’t even get the usual pop up that tell me Labview is going to shutdown and asks me if I want to tell NI about the crash. All Labview windows just suddenly disappear. Sometime when re-starting LV, I get a pop up about an ‘internal warning’ that occurred the last time LV ran.
We have tried numerous ideas to resolve, including opening the class independently from the project and re-saving (as suggested in another post), re-compiling, and checking all bundle and unbundle by name functions to ensure nothing got messed up during the re-order (as has happened to me in the past).
Now resorting to rebuilding this class, but this is a huge class could be many days of work. Any other ideas out there to re-pair this class?
09-22-2017 04:13 PM
Fair warning: I don't use AF. I have issues with lv crashing on classes though.
Here's one of my re-occuring crashes:
In a class where a child has an array of parents, and some vi's are (therefore) reentrant, lv sometimes crashes when child or parent data changes. Reloading the project gives different symptoms, but still crashes lv often. Sometimes lv doesn't crash, but the recursive calls simply don't return any data. Very hard to debug.
I resolve this by forcing "something to redo it's thing", by changing for all reentrant dynamic dispatch vi's 1 input\output from control to indicator or visa versa, and then back. This resets something, and resolves the issue. I made a scripting vi for this as there might be 10 vi's to reset (not available on my weekend tablet).
09-22-2017 06:03 PM
Thanks for sharing this trick! I will definitely keep this in mind for the future, as I often run into these issues.
Fortunately we seem to have resolved it now. Did a re-compile initiated from the ActorCore.vi, and was then able to successfully run after moving property controls (previous re-compile attempt didn't work, but perhaps missed some vi's). I still get a bunch of broken VIs each time I change the properties, and I did get one crash since, so I suspect I will be dealing with this again unfortunately. But have now made many changes to the properties and ran many times with only the one crash, so moving on...