Memory Leak with Private Events

[CGerspacher]

I believe I have found a memory leak with Private Events in Cloneable (and possibly standard) Modules.

In the "Obtain SEQ.vi" that is called by the "Obtain Request Events.vi" the VI obtains a reference to a named queue that is not cleared out by the immediate call to the "Read SEQ.vi".

When the obtain queue function is called with a named queue "the function searches for an existing queue with the same name and returns a new reference to the existing queue". This is stated in the documentation for the "Obtain Queue Function". https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/obtain-queue.html

This reference should be cleared by the "Read SEQ.vi" that is called immediately after the "Obtain SEQ.vi". See below screenshot for my temporary fix to test my suspicion.

This clears the memory and prevents the leak in my testing.

This leak was discovered by some testing I was doing that was calling many events (1,000,000+) and would eventually cause me to get to the point where I was unable to publish any events to the module as it would claim that a module was not running. My issues are no longer present after explicitly releasing the reference to the queue created by the "Obtain SEQ.vi". Unfortunately, I can't provide my exact code that was causing this issue, but if needed, I can try to replicate it with code that I am able to distribute.

[joerg.hampel]

Thank you for bringing this issue to our attention and for providing a detailed description. I've assigned issue #931. We will investigate and report back here. In all honesty, it could take some time as all of us are very busy at the moment.

[CGerspacher]

The error I was getting is Error Code 403684 Module Not Running. Posting this to potentially help others find it.

[drjdpowell]

In LabVIEW there is a hard limit of 2^20 live refnums of any one type, which is just more than a million.

[Darren]

@CGerspacher, just to clarify, you mention in the title of this post that the memory leak is with Private Events, but DQMH private events do not use the SEQ to store references... only Local Instance Events for cloneable modules do that.

I just wanted to make sure you were reporting this bug in reference to using Local Instance Events, and not Private Events. Thanks!

[joerg.hampel]

It was brought to our attention that we've been neglecting this topic for way too long. There isn't a good explanation other than we're all human, we only have 24 hours in a day, and maintaining the most popular 3rd party framework is a handful! We appreciate your understanding and your patience.

Bug #931 has been fixed in DQMH 7.1. We do have a beta release of 7.1 available, so if you're willing to take it for a test drive, please reach out to us.

If anyone needs a fix sooner, all you have to do is manually add the "Release Queue" function to your code in "Read SEQ.vi" as shown in the screenshot below.