Problem with a class moved on-disk; "something" still expects it in the old location.

[Mike Le]

A few weeks ago, I noticed that I'd messed up when saving a child class. Somehow, the lvclass file was located in the same directory as its parent.

 

I used the LabVIEW "move on disk" right-click operation to move the class to its correct directory.

 

I thought nothing of it until some weird project behavior started cropping up. I thought I'd resolved it last week. Hell, it could be a totally unrelated problem! But some very strange behavior came up today.

 

I was updating another class's private data to include a few arrays. When I finished that operation, trying to dynamically load one of that class's children led to a catastrophic, no-error crash of the IDE. The IDE just disappears and LabVIEW.exe shuts down. When I reopen LabVIEW, it gives no indication that it shut down improperly on the last execution.

 

Reverting to be backed, checking the run-time behavior, and then reimplementing the change confirms that changing the class data is the source of the problem.

 

This class is NOT the same class as the lvclass file I moved a few weeks ago. However, one of its child classes does call the moved class.

 

I tried running a Mass Compile and here's where it gets weird:

 

During the Mass Compile, it starts searching for the moved class in the OLD file location. If I point it to the correct location on-disk (by clicking "Browse"), then when the Mass Compile completes, it states:

 

Could not load (C:\Workspaces\V12000\Analysis and Plotting Tool\Plotting Legend\Plotting Legend - Graphing Actor.lvclass) because (C:\Workspaces\V12000\Analysis and Plotting Tool\Plotting Legend - Graphing Actor\Plotting Legend - Graphing Actor.lvclass) in memory

 

 

What's weird is that nothing but a Mass Compile will reveal this outdated file location pointer. Executing the code is fine, the project shows no Missing or Incorrectly Claimed items. If I do a snapshot of the folder I'm mass-compiling in a brand new project, then at no point does LabVIEW ask me to (1) resolve a conflict between two file locations or (2) locate a missing file.

 

If I perform a Move On Disk operation BACK to the original (incorrect) location, then the Mass Compile completes without errors.

 

I can Save All and the Mass Compile completes without errors. With everything that calls the class in memory (in fact, with my entire workspace in memory) I then do a "Move on Disk" operation to where the class SHOULD be. I Save All and perform another Mass Compile, which returns the identical "searching" behavior as previously; something is STILL expecting the class to be in its old location.

 

I've tried clearing the compiled object cache and deleting the mutation histories of all the classes in the Mass Compiled directory. I also tried clearing the mutation histories in several folders that might also be called as a result of dependencies. Nothing's fixed it.

 

Has anyone seen anything like this? I'll probably open a support ticket with NI tomorrow.

[ShaunR]

A few weeks ago, I noticed that I'd messed up when saving a child class. Somehow, the lvclass file was located in the same directory as its parent.

<SNIP>

Has anyone seen anything like this? I'll probably open a support ticket with NI tomorrow.

 

I have seen something eerily similar as it rings a lot of bells, but it was quite a while ago now so it's a bit fuzzy as to the exact symptoms I saw.

 

It was down to a full path of the class in an lvlib instead of a relative one. It may also have had the same in the class itself for a couple of methods; like I said, it is a bit fuzzy Once I manually edited the full path to a relative one, the problem went away. Might be worth seeing if you have something similar. It's easy to spot using a text editor

Edited September 3, 2014 by ShaunR

[Neil Pate]

I have seen things like this where "stale" classes were inside Diagram Disable Structures, everything generally ran fine until one day the build just broke for no apparent reason.

 

May be totally unrelated to your problem though...

[Mike Le]

It was down to a full path of the class in an lvlib instead of a relative one. It may also have had the same in the class itself for a couple of methods; like I said, it is a bit fuzzy Once I manually edited the full path to a relative one, the problem went away. Might be worth seeing if you have something similar. It's easy to spot using a text editor

 

Good news: this fixed the Mass Compile problem. I checked for the obsolete relative path in all my lvlibs, lvclasses, and lvproj files. I finally found it in an lvproj file. I fixed it and the Mass Compile no longer searches in the wrong spot.

 

Bad news: this did not resolve the bizarre "total IDE crash" behavior.

[Mike Le]

Okay, I think I've solved this problem.

 

I stepped through the code until the crash occurred, which led me to this accessor:

 

 

Originally, the "Test Cases" reference was not inside the "Refs" cluster. I moved into the "Refs" cluster. The bundle by name SEEMED like it had updated automatically, as you'd expect. But it was crashing every time it reached this accessor.

 

I deleted the "bundle by name" and replaced it with a new "bundle by name" node. The wiring's exactly the same otherwise. The code no longer crashes.

 

Somehow the "bundle" node had become corrupt, maybe pointing to the old data location? I don't know. I would never have thought to look for a show-stopping, IDE crash in a bundle node.

[shoneill]

^^ This

 

This is why NI needs to keep spending major time in refactoring / bugfixing the current IDE.  Stuff like this happens to me all the time.

 

Spend two days trying to find a seemingly impossible behaviour?  Oh, never mind, it's just that the IDE wasn't deploying VIs properly to the RT system....... Using an outdated file (correct local, incorrect remote)

[Mike Le]

I would definitely like the last 2-3 days of my productivity back.

 

I also feel like I'm a magnet for problems like this. I run into bizarre behavior far more often than my coworkers. It feels like I must have some awful coding habits or something that's leading to this. Or maybe I'm in a dysfunctional relationship with LabVIEW and am trying to make excuses for it?

[ShaunR]

I would definitely like the last 2-3 days of my productivity back.

 

I also feel like I'm a magnet for problems like this. I run into bizarre behavior far more often than my coworkers. It feels like I must have some awful coding habits or something that's leading to this. Or maybe I'm in a dysfunctional relationship with LabVIEW and am trying to make excuses for it?

 

It's a gift. Or at least you should look at it like that. I call it the Aura of Technical Doom - an innate ability to break anything technical sometimes just by mere presence. If you are a quality engineer with this special power, you are feared by corner-cutting engineers far and wide. These special people are also the bane of demonstrations and usually illicit the phrase "it was working earlier" from other engineers and sales people

Edited September 3, 2014 by ShaunR

[odoylerules]

Okay, I think I've solved this problem.

 

I stepped through the code until the crash occurred, which led me to this accessor:

 

 

Originally, the "Test Cases" reference was not inside the "Refs" cluster. I moved into the "Refs" cluster. The bundle by name SEEMED like it had updated automatically, as you'd expect. But it was crashing every time it reached this accessor.

 

I deleted the "bundle by name" and replaced it with a new "bundle by name" node. The wiring's exactly the same otherwise. The code no longer crashes.

 

Somehow the "bundle" node had become corrupt, maybe pointing to the old data location? I don't know. I would never have thought to look for a show-stopping, IDE crash in a bundle node.

 

I'm wondering if this behavior is related in anyway to issues we highlighted in this thread:

 

http://lavag.org/topic/18009-lvoop-object-control-element-accessing-via-bundle-vs-property-node/

 

It appears to have the same symptoms of what i and a few others were seeing.  A bundle by name was not correctly updating the data or was causing the IDE to crash.  I have seen this same behavior before and was shocked when i too narrowed it down to a bundle by name.  Mass compiles of my project were also causing a crash to desktop.  My solution was the same as yours, step through the program, replace the bundle by name and problem solved.  Nothing else changed. 

Edited September 4, 2014 by odoylerules

[shoneill]

I've seen bad type propagations all over the place.  Whether FPGA Refnums, User Events or stuff like this, incomplete Typechange propagation seems to be a major bugbear in the current LV codebase.