[Bug?] X-Control Memory Leak with Large Data Array

[jgcode]

[LV2009]

[Cross-posted to LAVA]

I have found that if I pass a large data array (~4MB in this example) into an X-Control, it causes massive memory allocations (1 GB+).

Is this a known issue?

The X-Control in the video was created, then the Data.ctl was changed to 2D Array - it has not been edited in any other way.

I also compare the allocations to that of a native 2D Array (which is only ~4MB).

Note: I jiggled the Windows Task Manager about so that JING would update correctly, its a bit slow, but it essentially just keeps rolling up and doesn't stop.

Demo code attached.

Cheers

-JG

[jgcode]

Note: There are some good comments in the cross post.

[Jon_S.]

Hello jgcode,

I think I can offer an explaintion for this one.  Each time through the while loop we are writing some data to the XControl.  This fires the data change event on the XControls façade.  The XControl runs asynchronously to the calling VI so the calling VI will run as fast as possible because there isn't a wait in the loop.  What happens is that the XControl executes slower than the while loop that is calling it.  This builds up the façade's event queue causing the memory growth.

More evidence to support this is try upping the wait in your loop to a time that would allow the Xcontrol to keep up (I used 100ms).  You should be able to run this VI continuously without the growth.  Moreover, if you run the VI as is and stop it before LabVIEW runs out of memory the OS will reclaim the memory implying that we aren't leaking memory but rather just using it.

Because of this I am considering killing this CAR as not a bug, but I wanted to get more feedback though.

[altenbach]

---

@Jon S. wrote:

This builds up the façade's event queue causing the memory growth.

---

That is exactly the reason why we need better control of the event queue in the event structure! 😄

See my ideas:

• Option to discard stale entries in the event queue
• Provide an event terminal for event queue size

A better solution to the current situation needs to be implemented!

[Jon_S.]

Agreed and kudos given.

[jgcode]

Hi Jon (cool name) 

Thank you very much for your reply. We came to this conclusion in the cross post and it is good to have it confirmed by LabVIEW R&D. Your response is also similar to that of my AE which I got this morning as well - see below:

Note: Your reference number is included in the Subject field of this
message. It is very important that you do not remove or modify this
reference number, or your message may be returned to you.

Hi Jon,

You probably found some information from the forum. The US engineer has gotten back and he said that unfortunately that's expected behaviour after they have conducted some tests and this is what he replied:

"X Controls in the background use events structures. In particular the Data Change Event is called when the value of the XControl changes (writing to the terminal, local variable, or value change property). What is happening in this case is the XControl is getting called to fast with a large set of data that the event structure is queuing the events and data that a memory leak is produced. It is, unfortunately, expect behavior.   The main work around for the customer in this case is  not call the XControl as often. Another possibility is to use the Synchronous Display Property to defer updates to the Xcontrol, this might slow down a leak." 

He would also like to know if you can provide with more details how you are using the Xcontrol, perhaps there is a better way. Please refer to the link below for synchronous display. Thank you.

http://zone.ni.com/reference/en-XX/help/371361G-01/lvprop/control_synchronous_display/

In my application I updated the X-Control @ 1Hz and it allocated at MBs/s up to 1+GB before it crashed, all within a few hours. That is why I called it a leak. I am really worried that if this CAR gets killed, there will still be an issue lingering that makes using X-Controls a major problem under the above conditions. I have had to pull two sets of libraries from my code because of this - when they got replaced with native LabVIEW controls the leak when away (but I lost reuse and encapsulation etc...).

Anyways, I really want to use X-Control tho (now and in the future) as I like all other aspect of them. If you do not consider this a leak, can a different #CAR be raised that may modify the existing behavior? I offer the suggestion (in the cross-post) that the data be ignored rather than queued? Similar to Christian's idea, but for X-Controls. Maybe as an option?

I look forward to discussing this with you further.

Regards

-Jon

[Ben]

---

@altenbach wrote:

---

@Jon S. wrote:

This builds up the façade's event queue causing the memory growth.

---

That is exactly the reason why we need better control of the event queue in the event structure! 😄

See my ideas:

• Option to discard stale entries in the event queue
• Provide an event terminal for event queue size

A better solution to the current situation needs to be implemented!

---

As applied to the event structure I agree, but to the XControl... I hesitate thinking that...

the trailer hitch on my truck has a clear weight limit clearly marked and if I choose to over-load it, should I expect the trailer hitch to unload some of the junk in the trailer?

And isn't the XControl just a triler hitch that I can couple my own (graphic) load too?

So if I find I start dragging something after overloading ... do I look at that manufactuer to fix the hitch or do I just keep the laod to something resonable.

I imagine the typo has been fixed but in the first LV Advanced course that included XControls ans part of the material there was line that stuck with that read something like "XControl are wicked hard to develop." large data sets where always the challenge. In the case of native LV controls, NI has specail backdoor approaches to updates via locals etc. If there was an area for improvement and speed, opne the back door for XControl may be the key.

Ben 

[SuperS_5]

Hi,

Maybe the simplest/quickest fix could be to make the calling VI wait until the x-control finishes updating.  (As an option of course) Something along the lines of synchronous updating, but for the whole x-control, and not just its FP stuff.  This would prevent the queue from overloading, and allow the programmer more flexibility.

[altenbach]

---

@SuperS_5 wrote:

... but for the whole x-control, and not just its FP stuff.

---

I don't quite understand what you are saying here. What's the "whole Xcontrol"?

We already can set any placed Xcontrol to "advanced...synchronous display", but this setting typically has other serious performance impacts.

[SuperS_5]

I have to stop posting when I am so tired.  I guess that I wasn't very clear.  Setting the "advanced>synchronous display" does not prevent this queue problem.  The X-control is still queued, then the code continues.  The actual execution of the x-control block diagram is asynchronous.  I meant the x-control's block diagram in its entirety when I said "whole x-control," as in completely synchronous execution.