LVOOP - VIs for Override will not execute if sibling is broken

[AristosQueue (NI)]

A) No, this is not by design.

B) No, this bug is not one that is known to LabVIEW R&D at this time.

C) Yes, I replicated this in LV2009 SP1 today.

D) No, I have no idea how this managed to get past testing before release.

E) Yes, there will be a CAR filed to get this fixed.

F) No, I have no idea how this has managed to go unreported until today. Well, I sort of do... I suspect that people phoned it in and it was assumed to be the "break 1 VI breaks the whole VI hierarchy" that was by design in LV 8.2 because a lot of people believe that's still the intended behavior, both inside and outside NI. The bigger mystery is why I or someone else on my team never noticed it -- we do quite a bit of writing LV class VIs, particularly small hierarchies to test variations on dynamic dispatching. Well, in any case, it's found now...

Thank you for posting this.

[shew82]

Great news! I cant wait till its fixed 😄

[Ben]

---

Aristos Queue wrote:

...

F) No, I have no idea how this has managed to go unreported until today. Well, I sort of do... I suspect that people phoned it in and it was assumed to be the "break 1 VI breaks the whole VI hierarchy" that was by design in LV 8.2 because a lot of people believe that's still the intended behavior, both inside and outside NI. The bigger mystery is why I or someone else on my team never noticed it -- we do quite a bit of writing LV class VIs, particularly small hierarchies to test variations on dynamic dispatching. Well, in any case, it's found now...

Thank you for posting this.

---

So its NOT supposed to break?

I did not know that.

Ben

[AristosQueue (NI)]

---

@Ben wrote:

So its NOT supposed to break?

I did not know that.

---

It is NOT supposed to break. Anything that should be broken will have something in the Error List Window. Listing nothing there is an indication that the VI is erroneously broken. 

[Tejinder_G.]

A Corrective Action Request has been filed on this (# is 215296).  You can check future releases of LabVIEW to see if this has been addressed.

Thanks for all the posts and helping us improve our products!

[AristosQueue (NI)]

After spending a couple days working on this, I know the nature of the problem. Unfortunately, we are too close to the end of development for LabVIEW 2010 and the change looks to be (surprisingly) substantial. I won't go into all the details here, but suffiice it to say that this is unlikely to be fixed in LV2010, and it is probably too large a change for the 2010 SP1, but it will be a top priority for LV 2011. If we can find some lower risk way to fix this than those we've identified so far, it might be possible to put it into the LV 2010 SP1, but hope is dim at this point.

I'm sorry for those of you who are working around this in your day-to-day work. 

[Ben]

---

Aristos Queue wrote:

...

I'm sorry for those of you who are working around this in your day-to-day work. 

---

Knowing the leg will heal will give me strength to fight through the pain rather than contemplating "auto-amputation".

Thank you Aristos !

Ben

[AristosQueue (NI)]

This is not going to make it into 2011.

The work required to fix this is extensive. I know it doesn't sound like a hard problem -- just don't break the subVI! -- but it turns out to be a logical consequence of the way the entire error propagation system is structured (the system that figures out when breaking one VI should cause another VI to break). We made a first pass at fixing this bug and decided we need another tactic, and it's just too risky at this point for 2011.

The amount of work required is substantial, and there is some consideration that perhaps it should just be left alone, given that there are other high priority items needing work, and that there are various ways to keep working around this bug. This is one of those rare cases that really pain me, where the work involved is unexpectedly high, the reward is fairly minimal for most users, but for the few users who hit this, it's a big deal. The risk-reward profile will make it hard to justify trying again for 2012, but -- let me stress -- we haven't made any decisions about this yet.

[SteveChandler]

What if instead of fixing it, LabVIEW just removed the inheritance from any class with broken dynamic dispatch VIs, disabled changing inheritance, and gave an explanation why?

[AristosQueue (NI)]

---

@Steve Chandler wrote:

What if instead of fixing it, LabVIEW just removed the inheritance from any class with broken dynamic dispatch VIs, disabled changing inheritance, and gave an explanation why?

---

Can't do that...

Suppose VI A has Parent on its block diagram and dynamically loads Child into memory while running. You run A the first time and Child is good, so A executes just fine. After that, Child is now in memory. Now you break Child. You cannot just disconnect Child from Parent and try running A again because there is data of type Child throughout A's block diagram -- the operate value of controls and indicators throughout the hierarchy, uninitialized shift registers and global VIs, and the last value of all the terminals along the way. That last group is the behind-the-scenes data copies for wires/terminals that are allocated to support the diagram that we leave allocated with their last run value because history shows that's the most likely to be needed again. We could probably detect that child is broken and deallocate these, but all the foreground values (control/indicators, USR, global VI, etc) we can't exactly just throw those values away.

No, given all the rest of the constraints on LabVIEW's runtime environment, this really has to work the way it works, generally, and this specific bug is a problem, but I'm not able to offer much help with it. There are two of us on Language that have worked on this problem and come up with nothing good. We've passed the CAR to another member of the team to see if he can offer any new approaches.