State change event will sometimes not be destroyed on SMO termination

[francois-normandin]

It has been reported that a memory leak occurs when destroying an SMO that is not owned by another SMO through composition. The state event is not destroyed by the object to allow callers to get a notification on self-termination of one of its children SMOs. This method leaks the reference if the SMO is standalone or if the SMO leaves memory before the caller has created a mailbox for the state event.

Fix will need to include that the SMO has an attribute to give it knowledge that it is "owned" by another process so that it can handle its own reference on shutdown when appropriate. Destruction when owned will need to include a callback from owner to acknowledge destruction of child process.

[francois-normandin]

The fix is actually quite simple. Because the owner already created a mailbox (event registration) to monitor the state of its dependencies (refer to Init state in the SMO:Process.vi loop), the act of destroying the source event after generating the state event change does not prevent the owner from receiving the notification. Therefore, one simply needs to destroy the state event refnum right after generating the destroyed (unknown) state event.

[jimkring]

👍🏻 -- Jim Sent from my mobile.