Intermittent error 1003 in Launch Actor.vi

[testingHotAir]

Hello,

I have a relatively simple actor that is giving me some odd errors when launching.  Sometimes, but not always, I get the following when I try to launch:

     Error 1003 occurred at Open VI Reference in Actor Framework.lvlib:Actor.lvclass:Launch Actor.vi->Drawing Management.lvlib:Setup Drawing.lvclass:Load App.vi

     Possible reason(s):

     LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

     VI Name: Actor Framework.lvlib:Actor.lvclass:Actor.vi

Opening Actor.vi, there are no errors.  However, when I watch Launch Actor.vi run, Open VI Reference returns the 1003 error as though Actor.vi were broken. 

If I close and restart LabVIEW, sometimes it will launch correctly.  My other actor based projects launch just fine.

Anyone seen this before or have any suggestions?  I've attached screenshots of my launcher and Load App vis.

Thanks.

[AristosQueue (NI) · Accepted solution]

I have seen this in one case. It wasn't a bug in LabVIEW... had to do with dynamic loading classes.

A VI is broken if it has a dynamic dispatch VI that can call to a broken VI. So if any class in memory has a broken override for a method, callers of that method are broken.

You can have a VI that is generally good, and then you load a class into memory and it breaks. If the VI is already running, then LV just keeps the loaded class off to the side so no one can instantiate data of that data type until the caller VIs all stop running, thus ensuring that no dynamic dispatch calls ever call into a broken VI.

What that means is that if you have a VI that you dynamically load into memory and in parallel you are dynamically loading a broken class into memory, it matters which one gets loaded first as to whether or not the VI is broken. If the VI loads first (and gets reserved because you asked for a strict VI reference), then the VI will be good. If the broken class loads first, the VI will be broken, and you'll get the 1003 error.

Is there any chance you're doing some sort of dynamic loading like this in your code? If not, I have no idea what's wrong. If yes, the solution is to either fix your broken class or to make sure that the VI is loaded first always.

[testingHotAir]

Ok that makes sense.  Everything is gravy until I hit the run button, which turns to a broken run button just prior to returning the error.  There is a lot of dynamic loading in this code (it's a configurator that loads the correct class structure in response to user input), though none of the classes have broken VIs that I could find.  Just before the problem popped up, I migrated some functionality from a child class to the top level class.  In the process I eliminated several message classes, some private data, and the associated accessors from the child class.  Is it possible these now-removed VIs, which of course broke when I deleted the private data they relied on, could still be getting loaded into memory?  Any way to check for this?

[testingHotAir]

Found it!

This standalone actor was being launched from other actors in my configurator.  Since the launcher wasn't set as reentrant, when the other actors were loaded into memory the launcher VI became locked.  Managed to catch the transient error in the Error Window by setting a break point before the Call by Ref node. 

I set both the launcher and the Load App VIs to shared clone reentrant execution and now have no problems.

[AristosQueue (NI)]

Glad this got solved.