LV Bug - Chart memory leak

[Matthew_Kelton]

If someone can confirm this behavior, I would appreciate it.  I went back to 7.1 and have seen the same behavior in 7.1, 8.2.1, and 8.5.

The waveform chart has a memory leak when the user clears the plot history via the pop-up menu (right-click on the chart while running, click Clear Plot History).  It is more obvious with larger plot histories.  The attached VI (7.1) demonstrates the problem.

If you run the VI and use the button to clear the history, you will see no memory leak (using Task manager to monitor LV).  If you right-click on the chart and choose Clear Plot History, you should see about a 4MB increase in memory every time you do it (this is for a 500,000 point chart history).

The VI the user in this thread wrote has a 170MB loss of memory every time the user right-clicks on the chart and Clears the Plot History.

[altenbach]

I see the same thing.

[Matthew_Kelton]

Thanks, you beat to the bug report list.

[parthabe]

Behaviour confirmed in LV 7.1!

[Nitin_T]

Hi Matthew

This was reported to R&D (# 4FQ225D) for further investigation. I've tried out the code here and I can notice the memory problem. Thank you for bringing it to our attention.

[Nitin_T]

Hi Matthew,

The memory usage problem is an expected behavior. The reason being, we back up the data we are clearing. This is so that we can "undo" some of the changes. There are only a certain number of undo steps that are available, hence the memory will be reused.

Message Edited by Nitin T on 12-04-2007 04:51 PM

[Nitin_T]

Hi Everybody,

Once again, just to make it clear. As pointed out in the "Waveform Chart memory leak.vi" (see first post), if we programmatically clear the chart, the issue of storing data for the "undo" operation doesn't arise. However, if we right click and use "Clear Plot History", as mentioned in the previous post, memory will be used to store values for the undo operation.

[Nitin_T]

This was reported to R&D (# 3ZOCC3LG), but was determined to be expected behavior. The reasons are as stated in the previous posts. The other CAR# (4FQ225D) was declared a duplicate of this (3ZOCC3LG). The Product Suggestion Center would be the ideal place to give detailed reasons as to why this feature should be changed, if someone strongly feels so.