Actors appear to shut down, but still lock their libraries. Code included.

[AristosQueue (NI)]

PS: Sorry... I don't have time today or this week to actually run your code. I'm kibitzing between other projects. After NIWeek maybe if you're still stuck.

[dsavir]

Hi,

I had the same problem. I have a controller actor that launches a GUI actor. They both inherit from the same parent actor MyActor, that has state data. I had the GUI actor send stop to itself on panel close, and the controller handle the GUI's last ack by sending a stop message to itself, that is:

Panel close GUI-> Stop GUI -> controller handle last ack->send stop to controller->controller closes all other actors in its stop core.

All the actor cores ended properly and there were no errors or running VIs. But all the classes (including MyActor and all the messages) were locked. In addition the project window was unresponsive or very slow, and LabView wouldn't exit - I had to use the task manager. But no VIs were running.

I fixed it by having the controller send the stop to the GUI, that is:

Panel close GUI-> send exit message to controller->controller sends itself stop message ->controller stops all actors in its stop core, including the GUI actor.

I realize it's good practice to have the VI that launched an actor close it, but I also have a debug actor that closes itself and doesn't cause any problems.

This did not have the same fix as Kaspercj as in WMS the controller launches and stops all actors. However, as the logger has the logger output file queues, maybe this is connected?

[Kaspercj]

Hi again,

My shut down route is pretty much the same as yours, but I still experience the locked library problem some times (the weird thing is it is not very consistent). I have tried two main methods of stopping the actors:

1. Stop button on GUI sends exit message to Controller > Controller sends stop to itself > Controller's Stop Core sends stop to all other actors.

2. I have also tried to make sort of a "stop core chain" where the Controller closes all the actors that it has enqueuers for and the other actors are then stopped by whatever actors that have the appropriate enqueuer (Logger stops Logger Output File for example).

With regards to method 1, does it matter in which order I send the stop messages in the Stop Core for Controller? Right now I just unbundle by name and wire send normal stop to all the enqueuers.

I find this problem really hard to debug because all actors appear to shut down and I can't find / don't think I have any flat vis that are left running..

[dsavir]

After fixing this bug with the GUI actor, I now have to fix with all the other actors the controller calls (I'm 99% sure this problem didn't occur in LV2012). In my case it's consistent (so far...): If the controller launches an actor the actor shouldn't close itself, but send a message to the controller to close it, even if the last ack is handled.

In your case, does anyone else need the logger output file queue? Perhaps the logger can launch and stop the logger output files, and the controller only launch the logger?

[dsavir]

So, after adding another actor to the controller and some more messages, we're back at the start:

controller launches GUI

User presses button on GUI

GUI sends message to controller

Controller launches actor 2

Front panel close in GUI

Gui sends exit message to controller

Controller recieves exit message and sends stop to self

Controller stops GUI and actor 2 in actor core

All actor cores end properly. Yet classes remain locked. Closing the project does NOT show the message "closing this project will abort some running VIs".

Back to the drawing board...

[Kaspercj]

Can you elaborate on this?

dsavir wrote:

If the controller launches an actor the actor shouldn't close itself, but send a message to the controller to close it, even if the last ack is handled.

What I am doing is having the GUI send a message to the controller to stop itself. This prompts the Controller's Stop Core and inside that stop core I have "Send Normal Stop" to every other actor. Is this correct or have I misunderstood something?

What really irritates me is that the problem is not consistent in any way. Sometimes I can launch / stop the program 10+ times in a row without any problems and sometimes it locks on the first run even after a fresh labview start.

If I press the X to shut down labview I sometimes get "Closing Labview will stop all running vi's" (can't remember the exact wording), but since the problem is very inconsistent it is very hard to debug. I have tried to install the Desktop Execution Trace Toolkit to see what happens during the shutdown procedure, but so far I can't find anything informative..

[dsavir]

See my earlier post, my fix doesn't work anymore... If it did, you are doing exactly right in any case.

Are you using LV13? Because I ported my project from LV12 and I don't recall this problem. I'll try porting it back and see what happens.

[dsavir]

OK, porting back to LV12 solved the problem. I opened multiple actors and closed them in different order, from themselves or from the controller or from an intermediate actor. No locked classes (as long as the actor cores exit properly, of course). Do you have LV12 you can try on?

[Kaspercj]

I ended up porting to LV2012 and have been running the project without errors so far. However, since the errors (locked library) were sporadic at best, I am hesitant to say that the problem is solved.

I will continue to develop on this 2012 branch of my project and if I don't encounter the problem again within the next few days then I will stay in LV2012.

[dsavir]

My errors were less sporadic, so I'm more hopeful ... I'll also give it a couple of days.