LabVIEW crashes when modifying OOP parent class private data control or typedef contained in that control

[AnthonV]

As soon as I find something concrete I'll post here. Thanks for the advice.

[ChuckDiesel]

I'm having the same issue in LV2012x32 on Win7x64. I have compiled code separated from the .VIs to play nice with source control. Most classes have the code included in the file (as is the default setting) but I have tried both ways on this particular class with no avail.

While I can change the name or type of an existing private data member (takes about 30-60 seconds to change), I cannot add new private data or add new elements to a cluster inside the private data without LabVIEW crashing. Straight exit to desktop a few seconds after adding the control and clicking "save" or "apply changes", no mention of sending error reports. I am also able to make a cluster within the private data into a type def with no problems, but when I add an element to that type def and apply changes it also crashes similarly.

This only happens in one of my bigger classes that spans a large percentage of the application. I am using the Actor Framework and have encapsulated different actors and their support classes/child classes into different .lvlibs.

I have tried restarting computer, restarting LabVIEW, force recompiling the entire project, saving, and restarting LabVIEW and nothing seems to help.

Approx. 1750 .VIs in total, ~50 classes (including children classes), ~68 megabytes.

I am out of options at the moment, and need to change the class data! Any updates here?

Chuck

[ChuckDiesel]

I restarted my PC again and now I get this message when adding a control to the private data:

[mikeporter]

Can you open just that one class and make the modification? My sense is that you may be suffering a case of over-objectification... 50 classes? Really?

Mike...

[ChuckDiesel]

Hi Mike, Thanks for the response and suggestion.

I opened the class separately and got the crash with reporter screen again, see below.

With the Actor Framework, I probably have even more classes. Each message is a class; add that to my UI objects, "sensor" objects, hardware abstraction layer, and all the different implentations of the above it adds up quickly.

[mikeporter]

I seem to remember having seen a few problems lately on the forum where LV was doing strange things and which were all using the Actor Framework -- and thus had a very large number of classes.
Another thought: How many times have you modified the data in this class? Whenever you modify the data type of the class data LV saves the old structure in a history of sorts to support the ability to mutate old objects to the new format.
The other night at the gathering at the Ginger Man, I overheard a conversation a LV developer was having about this very thing. If I see him today, I'll run this question by him.

Mike...

[Intaris]

Just to chime in on this one:

I've seen crashes of this type also.  I have also come to assume it has to do with incorrect propagation of changes but have never managed to actually track down the exact thing I was doing to cause the crash.

IMHO this is a big bug in LabVIEW which goes all too often under the "We can't reproduce it so it doesn't exist" flag.

The best solution here if you are able to package a project and reproducibly crash LV is to pack up the project and send it to NI with detailed information how to duplicate the problem.

Shane.

[AnthonV]

I am sorry to here about your crashes - it is such an inconvenience and a terrible ball-and-chain when you are trying to rapidly develop code.

My only solution is still to open only the .lvclass file by itself (no open projects or any other open vi's), to nudge a control in the class control so that the little modified star appears in the title bar and then to apply all / save all.  Usually before I do this I open all modified .ctl files (typedefs) individually, touch them and apply all / save all.  It helps if you are using a tool like subversion and check in often so that it is simple to find every modified ctl.

So far (touch wood) this has always worked for me.  The worrying thing is that it doesn't always cause a crash, I have found that suble unexpected behaviour is the result of changing a class control as the controls definitions are out of sync (my theory) and that member variables get mixed up.  I have seen this but cannot reproduce this on call.

Good luck.

[ChuckDiesel]

Aha!

Thanks AnthonV, this seems to be working for now. I am still experiencing some weird behavior but I am now able to modify the class private data after "twiddling" with the type defs and class private data separately, and saving the changes. Let's hope this trick continues working.

Chuck

[AnthonV]

Let's hope that soon this trick won't be necessary!