Another LV Bug? - A different chart memory leak?

[Matthew_Kelton]

If someone can confirm they believe this is a memory leak, I would appreciate it.

Again, I went back to 7.1 and see this behavior in 7.1, 8.2.1, and 8.5.  It appears to me to get worse with later verisons of LV, but they may just be my perception.

Two VIs.  With both, chart history is high (500,000).  You will see a huge jump in memory when the VI first runs (I am assuming this is LV pre-allocating memory for the history).  Both VIs plot data relatively quickly to demonstrate the problem.

With the VI that charts DBL's, you will see that memory holds steady after a few seconds and the chart updates.

With the VI that plots waveforms (this also applies to Signals as well), you will see the VI continuously eats up more and more memory.  Sometimes, I see it plateau for a little bit (a minute or so), but then it starts climbing again.

So it appears to me that LV has a memory leak when charting waveforms or signals.  The author of the VI in this thread has his system crash in 2 hours (although it's not yet confirmed that the chart leak is the only source of his memory crash as of this posting)..

[chilly_charly]

---

Matthew Kelton a écrit: ... With the VI that plots waveforms (this also applies to Signals as well), you will see the VI continuously eats up more and more memory.  Sometimes, I see it plateau for a little bit (a minute or so), but then it starts climbing again.

---

No such behaviour on my PC. After the initial jump, on the first run only, the memory occupation remains constant. on the other hand; the processor activity climbs up progressively to 100 % :O.  This bug will be difficult to track !

[parthabe]

cross-linked

[Matthew_Kelton]

No, this is a different one.  The one in the thread you linked to is a memory link when you clear the chart history.  This one is a leak just charting waveforms.

[parthabe]

Thanks for clearing my confusion.

[johnsold]

Matthew K,

I tried writing 500000 points to the chart history and that did not make much difference.

The size of the plot area on the chart is 425 pixels wide. It makes no sense to plot more points than that. When I converted the data storage to an array in a shift register (initialized to 500000 elements and using Replace Array Subset) and plotted only enough points to fill the plot area, the CPU usage dropped by a factor of 4-5 and the program stayed responsive through several million iterations. These results make me think that much of the problem is in the code which the chart uses to handle the excess data. Even with a preset chart history length, perhaps the code is not very efficient and continually reallocates memory.

Lynn

[Matthew_Kelton]

Lynn,

You're preaching to the choir here.  The user in the referenced thread posted he was getting crashes and when I was looking at his code in 8.5, I continuously saw memory getting sucked up using signals or waveforms.  When I switched to DBLs, the problem went away.

In my posted examples I saw memory leaks with data being plotted as low as 10k points.  I assumed LV was reallocating memory without leeting some go to do the plotting.

It is not my intent to perform a task with 500000 points of plot history.  I just saw that the original user wanted to do that and regardless of whether he has the resolution to display his history, LV shouldn't be leaking memory when he tries to plot that much data.

[johnsold]

I did not let the original examples run to 500000 points, but on some of the later things I tried, I noticed that the memory stopped increasing after reaching the chart history length. Writing 500000 elements to the chart history outside the loop did not prevent that memory increase. That is what lead me to think that it is a result of the way the chart handles data.

I thought you might be aware of the plot size issue, but it seems as though that needs to be mentioned from time to time for the less experienced users.

lynn

[altenbach]

---

Matthew Kelton wrote:
So it appears to me that LV has a memory leak when charting waveforms or signals. 

---

A chart of waveforms needs to keep track of much more data, because the points are no longer equally spaced, but each has a timestamp. If you are charting DBLs, there is no such problem.

So I don't know if it is really a memory leak or a reflection of the much more complex datastructures that need to be maintained internally. It would be interesting to know some of th details. I never use waveforms, though. 😉

[Matthew_Kelton]

Actually the waveform only has t0 and dt defined,  It is still assumed the points are equally spaced.  It just includes the x offset and multiplier for the graph/chart.

I also don't use them (I say that as I work with one right now), since I tend to use XY graphs and I've been using LV since before there were waveforms.

The complexity is why I put a question mark for my memory leak.  It just doesn't make any sense why LV preallocates memory for the chart, then grabs memory for every data point.  At face value, it seems that Lv is using twice the memory it should.

I am hoping that someone from NI will chime in here and explain the memory allocation for charts of waveforms and signals.  Because what I have seen through trying to helpe the user I referenced is that I really don't want to use waveforms.