Running yet Broken VI?!?!?

[JeffBoettcher]

This was reported to R&D (4FCC8K1W) for further investigation.  Thank you for pointing this out, and sorry for the confusion / inconvenience.

[Britoa]

No worries, like i said before, it was more amusing than anything (it doesn't seem to mess up running the VI, and I only noticed it because the unit I am testing only blinks one LED while running its 100ms job, so looking at the VI was about as exciting)

[Steve.Briggs]

Perhaps this reporting can shed light on something else within LabVIEW

---

Britoa wrote:

(...and I only noticed it because the unit I am testing only blinks one LED while running its 100ms job, so looking at the VI was about as exciting)

---

Lol..

[Britoa]

Alright, I can reliably produce the second part of this bug, and using the same project linked earlier.  (this one is more annoying to deal with)

If you set a breakpoint in one of these VIs that break when they run, and run it, you can't resume it, and you can't stop it, it really does become a zombie. 

I think TonP gets the prize for calling it a zombie first, it's the most accurate description of the problem.

(Ctrl-. doesn't work, the abort button doesn't work, unpausing it doesn't work, and the arrow, being broken, doesn't work.  you also can't step through the VI, because it isn't alive... mostly.)

[AristosQueue (NI)]

This is a fascinating case of every individual operation working perfectly and the collective doing something horribly wrong.
I have no idea why this wasn't encountered as an issue years ago. Here's the situation:

A class Alpha has two dynamic dispatch VIs, E1.vi and E2.vi. RunMe.vi is called by Alpha:E1.vi and calls Alpha:E2.vi. When you run a VI, any other VIs that use that VI as a subVI are broken -- you can't use a top-level VI as a subVI in LV. So when you hit the run arrow of RunMe.vi, we break Alpha:E1.vi. Because E1 is a dynamic dispatch member of the class, this breaks the entire class (because we can't set up the dispatch table correctly if one of the dynamic dispatch VIs is broken). That breaks Alpha:E2.vi. Because D2 is used as a subVI of RunMe, that breaks RunMe.vi. It leaves RunMe.vi in an impossible state -- running and broken, and LV gets confused about exactly what the VI's state is, and ends up crashing when you try to take that VI out of memory (at the close of the project).

At one level, this should be closed "Not A Bug" -- after all, each individual behavior was right. A VI running top level should break its callers. A broken dynamic dispatch VI should break the class. A broken subVI should break its callers. But put these all together in a  single system and BOOM, LV fall down and hurt itself. I'll be digging into this one for a while.

In the meantime, as a workaround, don't run RunMe.vi directly. Instead, drop RunMe.vi as a subVI of an independent VI and run that.

[NOTE] I have edited this post to use E1 and E2 instead of D1 and D2 since colon+D turns into a happy face like this 😄 and I don't see any checkbox on the forum to turn off the conversions.



Message Edited by Aristos Queue on 11-19-2007 02:38 PM

[AristosQueue (NI)]

The rules for replication may be a bit more complex than what I posted above. The nature of the problem is basically the same, but the trivial case involving a single class seems to be handled. I don't remember how or why we handle this. It seems to only cause breakage when extended to an inheritance hierarchy. 

Message Edited by Aristos Queue on 11-19-2007 02:54 PM

[Britoa]

ah ha! that explains why LV claims it crashed when I closed it and it didn't crash (or at least didn't seem to crash, as I have been working on this one project, and just select 'exit' from the project menu)

It is a good feeling when all of my current issues are all related to the same base problem.

Thanks for the update.

Edit: So can we officially call these Zombie VIs?

Message Edited by Britoa on 11-19-2007 04:41 PM

[AristosQueue (NI)]

No. Zombie VIs are the ones that won't die when you get the "Quitting LabVIEW..." infinite dialog of doom when trying to do File>>Exit.

These VIs do die -- at least, they crash LabVIEW, which although harsh, is a better death than the Zombie VIs which requires getting the Task Manager or other OS tool involved.  I have been on a campaign lately to add more undead monsters to LabVIEW, either in the source code, the documentation or the VI libraries. So if you'd like, you could introduce "vampire VIs" (because they suck the life out of LabVIEW) or something.

DUDE! This is so cool... I went to Google to get a list of interesting names for undead monsters that I could post here. And I found this: http://wiki.urbandead.com/index.php/Quartly_Study_Group
The Internet is amazing.

[Tomi_Maila]

Hi,

I'm trying to understand the concepts behing the problems presented in this thread.

1. First is there a particular reason why a class must break if a VI that is used as a subVI in a method of the class is executed? After all, the VI cannot anyway cause recursive call chains as these would have been detected by the compiler? Maybe I see the point if there were two top-level VIs executing in parallel.

2. Second is there particular reason why LabVIEW "breaks" a VI when it cannot be executed due to reserved shared resources such as running subVI. This is conceptually complitely different thing that breaking a VI due to compilation error. No matter what the solution to this particular problem is, I think these two issues needs to be conceptually separated.

3. Couldn't top level VIs always be their own instances. This would mean that there could be multiple instances of non-reentrant VIs but still only one (actually executing) instance per executing program. This would still guarantee that all subVI instances of the same VI would be the same. I admit this can cause problems with dynamically opened VI references as there would then be two alternatives that could be opened.

Tomi at 2 a.m.

[Britoa]

I think I will go with 'Ghost VI' as the VI, even after it stops, remains with us, haunting our memories. Even if Ghost VI doesn't work for you, it's definitely undead.