Reference leaks in JKI SMO

[_Mike_]

Hello all!

Did anybody also encountered reference leak from running SMO?

I have enabled Desktop execution toolkit, and after stopping my SMO thare are two entries of reference leak:

Details: Data Value Reference : 0x33500002

Call Chain:

-- Registry-SMO.lvclass:Obtain System Ref.vi

-- Registry-SMO.lvclass:Register Subsystem.vi

-- SMO.lvclass:Create.vi:6800003

-- CMMTE2.lvclass:CMMTE2.TestLauncher.vi

VI Path: C:\Program Files (x86)\National Instruments\LabVIEW 2015\vi.lib\JKI\JKI SMO\Registry\Obtain System Ref.vi

Thread ID: 0 --- CPU ID: 7

Details: VI : 0x19B00076

Call Chain:

-- SMO.lvclass:StartProcesses.vi:3690004

-- SMO.lvclass:Start.vi:1880003

-- CMMTE2.lvclass:CMMTE2.TestLauncher.vi

VI Path: C:\Program Files (x86)\National Instruments\LabVIEW 2015\vi.lib\JKI\JKI SMO\SMO\Private\StartProcesses.vi

Thread ID: 0 --- CPU ID: 7

The first one I succeded to suppress by inserting Delete Data Value Reference.vi in Registry-SMO.lvclass:Unregister Subsystem.vi, however i am not 100% sure it is supposed to ble closed.

I was unable to find solution for second leak.

Is this behavior intended, or we are in need for some small update to fix those problems?

[drjdpowell]

I don't know the SMO framework,  but "leaked" references like this are present by design in other async-calling frameworks.  In fact, I helped introduce one to the Actor Framework.

[_Mike_]

Thanks a lot for a suggestion.

However, I have few questions regarding to that. You mentioned:

Personally, I have no problem allowing LabVIEW to handle the reference.   Protected by a "First Call" node it is functionally identical to any on-diagram subVI with "Load and retain on first call" set.  It is not a "leak", even if it looks superficially like what might be a leak.

-- James

Could you explain it a little bit more wht it isn't a leak?

Also I had a problem with understandit "the root loop issue". Could i kindly ask you to brierly describe it?

[drjdpowell]

_Mike_ wrote:

Could you explain it a little bit more wht it isn't a leak?

Recently an application of mine crashed after 10 weeks of continuous running.  I used the Execution Trace tool to look for leaks.  I found a .NET reference to a small data structure that I had forgotten to close.  This data was produced once a second, and thus my app ran out of memory after creating and holding open about 6 million references.   That is a leak.

The Trace tool also pointed out many "leaks" that were of references that I by design intended to exist until something is stopped.  They were cleaned up automatically exactly when they were supposed to be, when the app stopped.  That's not a leak.

Also I had a problem with understandit "the root loop issue". Could i kindly ask you to brierly describe it?

Some loop deep in LabVIEW is required to be idle in order to do some things, including opening certain VI references.   Some User actions, most significantly opening a menu, can block this loop indefinitely. 

[francois-normandin]

Hello Mike,

Thanks for the report.

The SMO Registry allocates memory once when called, and as James pointed out, LabVIEW recycles it when the application is closed. This is by design. Closing the reference when you unregister an SMO wipes out the registry. You'll see in version 1.1.3+ that this reference will be closed when the last SMO is unregistered as this will explicitely remove the leak you saw while not removing capabilities. The registry will recreate the necessary reference if you create a new object after unregistering all of the previous ones. You would get a performance hit only if you continuously stop all objects and create new ones at a fast rate. (If that were the case, maintaining a top-level SMO that manages the objects being created and destroyed would remove this concern, as the registry reference would never be destroyed.)

I investigated the second leak report and couldn't find it whit my test systems (which version of SMO are you running?), but I have found two such leaks associated with the stopping of processes which are not present when running only the base class. These leaks are in "Register Process" and "WaitonProcessSync", and they can become a concern if starting and stopping objects multiple times without destroying them (pause-restart pattern). Expect those leaks fixed in 1.1.4+.

Francois

[_Mike_]

Thanks a lot!

I am happy to hear that there are going to be new developments in JKI SMO.

Is theer perhaps a hope for a bit more extended editor, which will actually show registered private & public methods/events?

I am still waiting for new video of yours on the topic, as I have some problems finding exact documentation of your shipping examples.

[francois-normandin]

Likewise, I'm happy to see there is interest in SMOs. I use them everyday and enjoy knowing how other developers find different design patterns or point to optimization paths.

State Machine Objects are an open-source project that we maintain, and we're happy with anyone giving feedback or even contributing to source code. I certainly agree with you that better Editor tools and documentation are needed to facilitate our life.