Get Object Memory Leak

[EthanHenry]

Hey Y'all,

          I've been struggling to pinpoint the origin of a memory leak for some time now, and recently realized that the code calls a vi pretty frequently, and this vi returns a ref of a class.  While looking through I couldn't tell if maybe it makes a new object each time it's called?  Anybody notice anything wrong with this method?

This is the subVI

That variant register holds an attribute for each class, and probing it while running shows that it returns a LabVIEW class, but I'm unsure if it's returning the same instance, or if it perhaps makes a sperate instance each time, which could cause it to become cluttered, since many vis call it every couple of seconds.  The VI That calls the top VI then takes the Object and casts it to the desired object type.  Thanks!

[Kyle97330]

Unlike many other languages, LabVIEW classes are data only.  Not pointers or references of any kind.  Simply pulling one out of a Variant attribute lookup shouldn't make a memory leak.  Even if the class data contains a reference, it doesn't make a new one, just a copy of the pointer it had to the one it already made when the class was stored as data in the Variant.

Though I would note that there are other cases that we can't look inside since you just posted screenshots instead of full files.

[EthanHenry]

Alright well the whole process is pretty long and complicated but I'll share the files that I believe demonstrate the typical life cycle, as well as a random objects method to get the Object using the tag.  Thanks!

[Jacobson-ni]

Have you tried looking at buffer allocations or VI memory usage by selecting Profile Buffer Allocations or Performance and Memory under Tools > Profile?

The first tool can make it pretty easy to identify specific, very large, memory buffers in LabVIEW (for instance seeing your variant attribute table grow as you add more classes). The second is more useful finding the VI that's growing in memory (or large number of clones which you might not have expected).

[EthanHenry]

I've tried the Performance and memory profiler before but didn't get much out of it, since it was just too much information.  I'll check out the buffer allocation and let you know how it goes.  Thanks!

[EthanHenry]

Alright I ran the Buffer Allocations and other than dictionary running about 3000 in a couple of seconds, everything is about what I'd expect.  Dictionary is called a lot of times but on the Memory vs time graph, it's a straight line with a couple of drops.

[DerrickB]

There's nothing that looks fishy in that variant database code, unless there's a bug in LabVIEW (doubtful, you're doing pretty common stuff there) there's about a 99% chance the problem is elsewhere in the application.

I'll second the recommendation for profiling memory usage. If you're having memory issues it's the tool you have available to you. It's only too much data to you because you haven't learned how to interpret/sort it yet. There are some things that don't show up in there but that's almost as helpful as that narrows down what the issue could be.

I'd be curious to see how quickly the memory is rising in task manager or performance monitor and what the memory details show from the LabVIEW tools.

[LucianM]

---

@EthanHenry wrote:

Hey Y'all,

          I've been struggling to pinpoint the origin of a memory leak for some time now

---

How big is the leak? How did you measure it?

[EthanHenry]

I whipped up a small python script that measures the amount of private memory dedicated to the exe every 5 seconds, and let it run for an extended period of time.  I then whipped up another script to help graph it, and I got the following

Which doesn't look too bad till you zoom into the "flat" part and see

The Y axis is in Bytes and the X axis is in 5 second intervals.  The Blue Line is the actual data, The Green Line is a line of best fit for all of the data, and the Turquoise Line is the Max value (so I can see if it's growing or not).   So yes it's not a very fast increase in memory, but it is steady, and since this application is supposed to be run months on end, that time adds up.

As for the Profiler, I attached the Memory Profile, and got the following for the buffer allocation

Thanks again for all your help!

[rolfk]

IMHO you are looking at noise here.

So you have an application that on startup jumps to 9*1E8  bytes of memory, falls back to 8.119*1e8 bytes and then slowly increases to 8.126 * 1e8 bytes with a clearly visible asymptotic curve.

That is a jump to 900MB, then going down to 811MB or so and then slowly and asymptotically going to 812MB over a period of 10000 seconds. This is crazy constant for a memory footprint! If that's your only problem for this app you are done! And yes even if you let this run for a month. Unless you can show us a continuous linear increasing memory line, there is simply nothing to be seen here! Please move on!