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)
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-200702:38 PM
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-200702:54 PM
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.
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.
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.