class ownership confusion

[Thoric]

I've been bashing my head against the proverbial wall for a couple of days now trying to understand what was corrupt in my LV project hierarchy. On the face of it, all appeared to be fine, but I was getting some very unusual errors when executing my VIs. Errors that hadn't occurred before I rearranged stuff. In my project I have a number of classes, with various inheritances and other defined relationships, and I recently moved some things around to make it, well, better organised. I ensured I didn't destroy the relationships required to maintain access to class methods etc. Indeed, after the rearrangement, there were no broken VIs, and a mass compile (for good measure) came back clean.

 

Now, although the majority of my classes were working fine, I had a very bizarre "Out of Memory" error occurring when accessing the private data of one particular class's DVR via an in-place structure. The private data of the class is nothing more than an array of a cluster of elements. Typically the array is empty, and in the in-place structure I am combining the contents of one class's array of elements into another's. And indeed, in the above error case I had two empty classes, so the build array function had no real work to do, yet I saw some very odd behaviour.

 

Firstly, when highlight execution was on, the array datawire from the unbundle terminal of the in-place element structure should show "#0" to indicate no elements in the array, but in fact would regularly show #84 for one, and I would never get to see the other due to the "Out of memory" error. This was very repeatable, even after rebooting my computer. Where was it getting 84 elements from!?

 

In a generic probe place on the class itself I would see that although the class wires showed normal content (zero elements in their private data), their Value field showed an incorrect namespace entry. This class is owned by a single library, so the namespaced title is mylibrary.lvlib:myclass.lvclass. However, the probe's namespaced title was mylibrary.lvlib:sublibrary.lvlib:myclass.lvclass, where sublibrary.lvlib is a library definition that I emptied and removed a few days ago. Yes, the class used to belong inside this library, but no more. In the library project view, the class can be confirmed to live directly within mylibrary.lvlib only. sublibrary.lvlib isn't even on the file structure anymore, it's literally gone - yet LabVIEW didn't seem to recognise this conflict.

 

After seeing this I realised there was a corruption, but I couldn't see how to properly inspect the defined class ownership properties, or influence it? There's nothing under the Properties panel accessible from the right-click menu? I wondered if dragging the class out of mylibrary.lvlib and back in again would help, but it is changing these ownerships that caused this mess in the first place, so I decided to close down LabVIEW and overwrite the myclass.lvclass file on disk with a backup from earlier that pre-dated the original move into sublibrary.lvlib.

 

Voila, this solved my issue immediately.

 

So I'm quite perturbed to see that a bad ownership property in a class can cause LabVIEW to keel over with very odd execution behaviour, yet otherwise believe everything is fine in the hierarchy itself. Is there a way to inspect class ownership properties throughout a project to look for inconsistencies? To validate the information already there? I already tried a mass compile and that didn't resolve it.

 

Now, I actually want it, and some other classes, in sublibrary.lvlib, contained within mylibrary.lvlib, but I've been trying for two days to recover my project after trying this once. I wonder now if I even dare try to rearrange my classes again!

[Aristos Queue]

a) What version of LV are you using? The issues you describe were in LV 8.5 but fixed in 8.6 and later to the best of my knowledge.

b) It is hard to help analyze anything without code. Have you opened a service request? Do you still have the corrupted versions?

[Thoric]

Hi Aristos,

 

This is LV2011SP1. I wanted to try discussing the issue without code because it's part of the PTP Sequencer toolkit. However, I guess it doesn't really matter too much, so I'll be more accurate. I was rearranging my classes to the following structure:

 

PTP_Sequencer.lvlib

  - ptp_sequencer_public.lvclass

  - ptp_sequencer_core.lvlib

    - ptp_sequencer_element.lvclass

    - ptp_sequencer_container.lvclass

    - ptp_sequencer_loop.lvclass

    - ptp_sequencer_branch.lvclass

    - ptps_ps_service.lvlib

      - ptps_pub_sub_service.vi

      - (lots more classes)

 

I have everything under PTP_Sequencer.lvlib currently, and I'm trying to add ptp_sequencer_core.lvlib. When I create the _core library and start moving the classes into it, that's when all holy hell breaks loose. Although LabVIEW doesn't complain about the move, things start getting weird afterwards.

 

I didn't want to create a service request because I suspect I'd be told "these issues are resolved in LabVIEW 2012...", but I want the toolkit developed in an older release to ensure compatibility with as many users as I can. I can't go older than 2011 due to the use of a few features that came out in that release (DVRs?).

 

I may still have the corrupted versions because I've been backing up to separate folders at regular intervals to ensure I can revert easily. I'm about to try to achieve the above hierarchy again anyway, so I'll probably have a new corrupt version in a few minutes... 

I'm about to try to achieve the above hierarchy again anyway, so I'll probably have a new corrupt version in a few minutes... 

Well that didn't go well. LabVIEW popped! 

[Thoric]

Creating a virtual folder, moving everything into that, and using the "convert to library" feature seems to have worked. It needed a mass compile to resolve the masses of errors that were created, but it may be I have a working structure now. Some further testing is needed to be confident...

 

Edit: After further testing it appears that some of the friendships between XControls and classes were not migrated, so a friend of the XControl previously at:

PTP_Sequencer.lvlib:class.lvclass

that moved to

PTP_Sequencer.lvlib:ptp_sequencer_core.lvlib:class.lvclass

was still listed in the XControl's Friends tab as being at the original namespace path. Therefore it lost it's friendship which broke some VIs. Simply removing the invalid class friendships and re-adding them solved this issue. 

Edited September 3, 2013 by Thoric

[ShaunR]

I had the same sort of problem the last week I made a lvlib that contained only two classes (no inheritance or anything complicated).

 

I'm terrible at moving stuff around on disk outside of a project to get it "organised". I then close the project, re-open and let labview find or ask me where things are and let it re-link. LV is usually pretty good and without classes this has never been a problem.

 

In this instance it just wouldn't forget an old class name that I had used previously and a couple of VIs were still linked to it-apparently. It only showed up when trying to build a package where it would show the finding dialogue and report an error of xxx.lvclass not found and the build would fail. There was no indication in the project that anything was a-miss (no broken VIs and nothing in the dependencies). Eventually, I searched all the files with a contents search to find what was linking to what (no other way of knowing) and once I found out which ones; disconnected them from library and re-added/re-saved. This fixed the problem but it took some hours to find and my bald spot now covers the rest of my head with all the scratching.

 

. I have vague recollections of a thread on here about similar behavior being reported, then fixed, then coming back again.

Edited September 3, 2013 by ShaunR

[Thoric]

Very similar to your experience, the project reports fine but it's VIPM package builder that's failing to build. Once I sorted out these oddities it builds fine (albeit very slowly now?)

I'll check out your link Neil, I think it might be great to dissolve the mutation history. I can't see why that would be useful once a library is set in stone (which I hope it now is).