Project explorer freezes when moving around certain classes/lvlibs... how to debug?

[BertMcMahan]

So I have some combination of classes and/or libraries that are just flat out not playing nice with my Project Explorer. I initially found the problem when I tried to use right click -> New Interface, which froze the project explorer. (Note: if I said "don't save it", it worked fine, it was trying to save it that screwed things up).

Turns out it's one specific library that's giving me trouble. It's got about 4-5 actors in it from the AF plus a few message classes, so fewer than 10 total classes, and one XControl.

I rolled back my SCC to find when I could successfully create a new Interface and/or move Interfaces into the library, then recreated the offending class as best as I could. When I tried adding that to the library, same deal. Frozen project explorer, had to hard exit LabVIEW.

I originally suspected the XControl, because it did get corrupted at one point, but rolling back SCC to the point where I could add/remove libraries showed the XControl was already in there.

I unfortunately cannot attach code, but my more general question is... how the heck do I debug this? Is there some way to get insight into what the Project Explorer is doing? I've tried disconnecting libraries, recreating them, rolling back code... I can't figure out what's locking things up. If I could tell which step is failing then perhaps I could figure out what's corrupted and solve it, but I have no ideas here.

[BertMcMahan]

A bit more info...

It appears to be one specific class (call it Demon.lvclass) that's preventing me from saving other libraries/classes/interfaces. And, if I create a second project and add Demon.lvclass to it (so LV says it's Locked), it still locks up the Project Explorer.

Oh, and the XControl wasn't even in this class originally (though I've removed it for now). No idea how this class could affect OTHER classes/libraries in the Project Explorer.

[Kyle97330]

For why it merely being in memory is an issue, I do know that if a class is just in memory and it shares a Dynamic Dispatch call with some other VIs in memory in its same inheritance it does look at all classes in memory to check that all Dynamic Dispatch calls that might happen during execution aren't broken, because LabVIEW just assumes that if a class is in memory then it might appear on a wire and need to call one of its Dynamic Dispatch VIs, even if in your program there is no way for it to get put on the wire in the first place.

So if during the "save" process there is something that checks to see if members of one class are runnable, it's conceivable that it would then look at other classes in memory to determine this.

So maybe you could find all of the Dynamic Dispatch calls in Demon.lvclass and remove them (temporarily, for testing) and see if doing so "fixes" the problem.  (If any are required overrides you could remove them and create new ones that are empty.)

If removing all Dynamic Dispatch calls in Demon fixes it, then you can add them back in one at a time and see if it's all of them that are an issue or just one of them.  And if it's one of them, then you can check to see if that VI is corrupted somehow, or if there's a specific subVI in it that causes problems when present, and so on.

There might be other instances where classes "look" at each other even without a direct relationship, but none that I know of.  You could still try the same method with other members of Demon that aren't Dynamic Dispatch too, to yet again narrow down the problem.

[JÞB]

Wild guesses

• Are there any autopopulating folders?
• Is the SCC checkout folder locked preventing a write to any callers when namespaces change?
• Try clearing the object cashe and Save all this project

[BertMcMahan]

Thanks for the tips. I understand about the class being locked, I was actually doing that intentionally to make sure LV wasn't trying to write something or change anything. Didn't seem like it helped.

I did clear the object cache and save everything, didn't help. No autopopulating folders. No locked folders as far as I can tell; I use SVN and haven't had any locked folders before.

At this point I think I'm going to just rewrite the class, since it was only like 5 or 6 VI's. Most of my troubleshooting time was just figuring out what the problem was, as I'd changed maybe 20-30 VI's between SCC commits that day. Once I narrowed it down to that class it's not a huge effort to rewrite it, though it's definitely a few hours I'd rather not have lost!

I'll try removing things from dynamic dispatch and seeing if that fixes anything. It's really odd, because all of the VI's seem to open and view just fine. It's just when trying to save that things break.