Libraries locked after running

[Ben_Phillips]

Sorry for the long post, but I've been down many roads trying to find out what is causing this, and end up disappointed each time, with code reverted yet again in my legendary chimera chases.

I'm trying to get to the bottom of why my libraries are all locked after I run my project (obviously have some work to do on inter-library dependencies, if certain libraries lock a bunch of others).  I understand that leaving a rogue actor running will do this same behavior, but I don't see any place that could be happening.  If I put a dialog at the end of the stop core of all known actors, I see them on the shutdown.  It shows the same thing since I've added a general logger for all Handle Last Ack Core methods, simply stating in a console window that someone has stopped.

I can run my project in source code over and over, with no apparent problem.  But the libraries are locked after first run.

If I open VI hierarchy after the project has 'stopped' and see an instance of  Framework.lvlib:Actor.lvclass:Actor.vi.ACBRProxyCaller.D5200089

does that have any relevance here?  Does that conclusively mean that an actor is still running somewhere?

The last message logged in the debug logger in the debug fork says: [0 Time-Delayed Send Message Core.vi.ACBRProxyCaller.D5D0007D] sent message 58 to [0 ?] [Error]

I'm pretty sure this is just the result of the message queue having been destroyed on shutdown, and the time-delayed message loop stopped, no apparent problem.  The debug actor does stop showing new messages being transferred.

Is there anything I need to worry about with infinite time-delayed messages not being shut down, if I don't manually do it myself?  Looking at the code inside there, it doesn't seem like it should create a bad situation if the actor being messaged shuts down without an explicit 'Stop All Messages' notifier being written, since if the enqueuer goes bad the time-delayed message loop will stop.  I did notice that putting an emergency stop instead of a normal stop on a data publishing actor with a recurring publish message resulted in that publish message never stopping, even after all of the other actors seemed to have shut down, including the top level. 

Putting an asynch process (but not an actor) inside a subpanel in an actor, and not having it shut down before the top level exits, could that cause this behavior?  Specifically, does it matter for this behavior whether I am careful to remove the VI from the subpanel before the actor shuts down?

When I first open the project, some actor cores open as broken.  But either force compiling or running it unbreaks it, and that's the last time that happens while the project is loaded.  Could this be related?  I have no idea why this happens, although it's not much trouble to deal with.

Has anyone else had this problem?

[Daklu]

Ben_Phillips wrote:

When I first open the project, some actor cores open as broken.

I doubt I'll be able to help you, but what error are the actors reporting that causes them to break?

[Ben_Phillips]

They're not reporting an error, it just shows a broken run arrow.  If you click it, it spontaneously fixes itself and starts running.

[David_Staab]

It's probably something with the LV linker/compiler stuff. I've seen it multiple times in my AF projects in LV2011. Try CTRL+SHIFT+RunArrow on the top-level ("launcher") VI, then save all. Sorry for what that'll do to your SCC, but it's worked for me in the past. If it doesn't, try these things next:

• Disable the "removed compiled code" feature and save all VIs again. I had to do this in one project that kept corrupting itself. Again, it's no fun for your SCC repository, because edits in an AF project often lead to dozens of recompiled VIs.
• If there are specific offending VIs causing the problem consistently, try copy/pasting their code into new VIs and deleting the old ones. I had an issue with one project where three VIs in an AF class had become corrupted and kept crashing my builds. When I copy/pasted the code into new VIs and replace the existing class methods with them, everything built fine.

[fabric]

Ben_Phillips wrote:

Putting an asynch process (but not an actor) inside a subpanel in an actor, and not having it shut down before the top level exits, could that cause this behavior?  Specifically, does it matter for this behavior whether I am careful to remove the VI from the subpanel before the actor shuts down?

Not sure if this is anything to do with your locked libraries, but it is definitely a good idea to remove an async VI from its subpanel before closing the hosting VI. I've experienced nasty memory leaks by closing the host without cleaning up first. (Mind you, I was also using doing some hWnd voodoo with win API calls at the same time...)

[tst]

Ben_Phillips wrote:

Putting an asynch process (but not an actor) inside a subpanel in an actor, and not having it shut down before the top level exits, could that cause this behavior?

Since you're doing that, I'm guessing you're doing something like this:

I found that this causes the class to stay locked, and you need to change the type specifier, so that it's not linked to the VI, like so:

I left the strict reference there as well, so I can regenerate the constant quickly if I change the conpane.

And yes, there's no error handling on that part. Shame on me. I probably should add it in.

[Ben_Phillips]

I've narrowed this down to a single instance of starting off an infinite recurring message at 5000 ms at the beginning of actor core for a rather simple actor.  Comment that out and libraries are not locked after shutting down.  Even if I comment out the Do case of that message, and even if I go further and just make it the base AF message that is being sent, and be sure to keep track of the Delivery Notifier and stop all further copies at stop core ... the libraries remain locked.  Very bizarre, I cannot see why this is a special case...this same technique is used many places without problem.

I'll update here when I figure out what the problem is.  This at least gets me most of the way there, I'm only missing a visual update on a worker by removing the offender.

Thanks for the help so far...

[Pocobor]

Did you solve this issue?  I am also having a similar problem. 

I have two actors which control analog and digital functions on a DAQ, and these two seem to lock all the libraries after running.  I shut down these actors normally and end their processes, but the all the libraries in the project are locked after running, even the ones that I'm not using.   I can't figure out what's happening, and I have to close the entire project to get access again. 

[AristosQueue (NI)]

Pocobor: Ninty-nine percent probability: One of your actors isn't really stopping. There's a little boolean input on the Launch Actor.vi at the bottom for "open front panel when launching". Try setting that to true on all your launches and then run... see which one isn't stopping.

[Pocobor]

That was a great tip.  I was having so much trouble finding what was still running when I hit stop.  It was a small wiring bug staring me in the face the entire time.

Thanks.