Bug in Actor Framework 3.0.7 - Unclosed References

[SteveChandler]

I made a very simple Actor. I have an event structure with a single boolean value changed event for stop. That event sends a stop message to my actor and stops the loop enclosing the event structure. It cannot be simpler right?

I ran it and it works. Whenever using queues or any kind of reference I always run the Desktop Execution Trace Toolkit to make sure I am closing everything and there are no unexpected and unhandled errors. I am getting an invalid reference error and a reference leak.

I then loaded the feedback cooler example and ran DETT against it and I am still getting errors and reference leaks.

Are these known issues? Am I being too OCD about these kinds of things? I attached a trace for the example above and for the cooler demo along with a text export for each.

[justACS]

We'll look into this, though perhaps not until after the 1st of the year.

[xkenneth86]

Anything further on this? I'm getting the same issues.

- Ken

[AristosQueue (NI)]

Honestly, it fell off my radar. Thank you for the reminder.

I dug into this just now... two separate issues. One is a bug/feature/aspect of Launch Actor.vi  and the other is a bug in your code. How's that for balanced? 🙂

The leaked reference report is caused by not having an explicit call to Close Reference matching the Open VI Reference in Launch Actor.vi. The Close is unnecessary in this case. An Asynchronous Call By Reference node called in Call And Forget mode automatically takes over closing the refrence given to it when the VI that is called and forgotten finishes running. The reference isn't leaked, but it is not explicitly closed, either. An explicit close does no harm, so for the sake of not having any alerts from DTT in the future, I will consider adding the Close Reference to Launch Actor -- if you want to add it to your own code, it goes right after the ACBR node. However, you should ignore the error out from this node, and explicitly ignore it. I am pretty sure that there is a timing window problem -- the ACBR could start running *and finish running* in the small space of time between the ACBR node and the Close node. In that case, the refnum will already be closed by the automatic system, and so the Close node would return an error. Since that's a rare case, I won't worry about it showing up in the DTT, but it would if it happened. Aren't references fun?

The error message is your code. You're firing the Send message and then destroying the caller queue... without waiting for the send message to actually be fully processed. So by the time the nested actor fires the Last Ack message, its caller has already quit. That's ok ... the Actor Framework is designed so that a nested actor doesn't care if its caller is no longer around to hear the last ack. But it does generate an error, an error that gets handled in the code. If you want to avoid the error, you need to wait until you get a LastAck message from the actor, as shown below:

[jcase]

AristosQueue wrote:

The Close is unnecessary in this case. An Asynchronous Call By Reference node called in Call And Forget mode automatically takes over closing the refrence given to it when the VI that is called and forgotten finishes running.

This is not true. You must close the VI reference and if you do not, it is a leak. Of course, LabVIEW will automatically close the reference when the calling VI goes idle. However, you do not want to depend on this.

It is safe, and normally recommended, to close the VI reference used in the Async Call By Reference Call and Forget (ACBR C&F) use case immediately after the Start Async Call node is called. Close the reference after you are done with it. ie: Not needed for another call, property/method call, etc.

For a Call By Ref and an ACBR C&F, there is an internal concept that will keep the target VI in memory as long as it is running. When the target VI completes, it will automatically leave memory if there is nothing else keeping it in memory (such as a VI reference or an open front panel).

The ACBR Call and Collect use case is different. In that case, closing the VI reference will abort the target VI so you would most likely not want to close the reference until after the Wait On Async Call successfully completes. In general, running is not a reason why LabVIEW will keep a VI in memory. The CBR and ACBR C&F are the main exceptions.

I think AQ thought the ACBR C&F behaved more like the VI method Run VI with true being passed into the Auto Dispose Ref parameter. In the Run VI method, ownership of the VI reference is transferred from the VI that opened the reference to the target VI. The VI reference will help keep the target VI in memory. If you close that reference, it is possible the target VI will abort and leave memory. In the ACBR, ownership of the VI reference is not transferred.

AristosQueue wrote:

However, you should ignore the error out from this node, and explicitly ignore it. I am pretty sure that there is a timing window problem -- the ACBR could start running *and finish running* in the small space of time between the ACBR node and the Close node. In that case, the refnum will already be closed by the automatic system, and so the Close node would return an error.

This is not true. There is not a race condition. As I described above, when performing an ACBR C&F, it is actually recommended to close the VI reference immediately after the call to Start Async Call.

AristosQueue wrote:

Aren't references fun?

This is true. They are fun.

[AristosQueue (NI)]

Thanks, jcase...

I asked jcase to review what I'd written because he's the expert on this feature. So, we do need to add the Close Ref to Launch Actor.vi. I'll file the CAR.