LVOOP and Crashing

[10Things_Rob]

Looking for some expert advice...

I have a large project (3000+ VIs, with lots of classes).

I am developing on multiple different computers, and using good configuration maangement practices (with SVN)

This morning I was working on the code, and at some point LabVIEW crashed. And now the project won't open.

The crash log seems to indicate the problem resides in a method of a class - one of its inputs is a STYP cluster which contains an object and LV can't figure out what to do with it

So, I think, I'll just revert to an old copy, one that I KNOW opened on my machine in the past. No Dice. Crash. <--- At this point I am very concerned and confused

OK, I'll go open the old code on my second machine (before my AM mods, the same old code I just got from SVN)... works fine.

I am in the process now of updating the code on the second machine, which I will then check in and see if THAT code will open without crashing on the original machine

So some questions...

• Any idea what the heck could be going on?
• I suspect that LVClasses are FAR more likely to cause crashes/problems if the VIs that call them are set to Read-Only on disk (I have "Treat Read-olny CIs as locked=TRUE), can anyone back me up on that?
• I had a problem like this once, and cycling power on my machine solved it. Why should that help? It doesn't in this case.
• Any other pointers on good practices to avoid these kinds of problems?

NOTE: I have not hit the run button, nor have I opened any other projects at the same time or anything

NOTE: I have confirmed that OTHER codlines using the same set of user.lib libraries and such still open fine

NOTE: LV 2014 SP1

I will try to provide more updates if I see anything else of interest.

[mikeporter]

Assuming that you are using the actor framework (I'm not sure how else you would get to over 3000 VIs and lots of classes) that is the first place to look.

I have never experienced crashes related to lvclasses being read only.

It is certainly possible that when it crashed, LabVIEW got corrupted. Haven't seen it happen recently, but it does happen.

In terms of solutions, don't create applications with over 3000 VIs. As with many things, if working in LabVIEW becomes a pain, you are doing something wrong.

Mike...

[Jacobson-ni]

I would be interested in taking a look at the zip file generated by the crash if you are willing to post it.

Also, has this crash happened before or happened again, or was this a one time thing?

[Bob_Schor]

I'm sure you've done this, but I've occasionally found obscure (well, I don't want to call them "bugs", let's say) "unexpected features" in my code that don't necessarily show up as Errors, particularly if they are invoked at Run Time and the name is "constructed" on-the-fly.  So one thing I try to remember to do when I have any "unexplained behavior", yet my code doesn't seem to have any Broken Arrows, is to look at the Dependencies and see if I see anything I don't expect, such as a "hidden conflict", a hidden "missing VI", or a VI that is used by the Project, "lives" in Project "space", but was never formally "added" to the Project (this is easily fixed by dragging it out of Dependencies into its proper place in the Project Tree).

So if you haven't looked in Dependencies, I recommend it, and would be curious if it reveals anything unexpected.

Bob Schor

[tst]

---

@10Things_Rob wrote:

So, I think, I'll just revert to an old copy, one that I KNOW opened on my machine in the past. No Dice. Crash. <--- At this point I am very concerned and confused

---

My guess - corrupted compiled cache. I don't remember hearing about something like this specifically, but that would make sense as something that wouldn't be affected by a revert and would be different between machines. Should be easy enough to check by clearing the cache (in Tools>>Advanced) and then opening the code. Of course, this will also cause all of your other code which is separated to load more slowly the next time you load it, because it will have to recompile.

You could possibly also try saving a copy of the cache file first if you want to hand it over to NI for debugging (should be in Documents\LabVIEW Data\VIObjCache)