Application is eating memory

[1984]

Hi,

We developed an app to our customers about 9 months ago which he started to use extensively in the past couple weeks (manufacturing ramped up). Since then the application throws a "not enough memory for the requested operation" popup once in about every day. Once the popup showed up the app has to be restarted which is certainly not what they want.

I implemented a routine which logs the memory consumption of the application and it grows pretty steadily all the way up to about 3G and after that application tends to drop that popup. The growth rate varies but I can say that its around 2-3MB per minute.

The problem also affects the uncompiled code. The graph attached is made while I run the labview source code, in this case I measured the memory consumption of the LabVIEW.exe. There are these weird drops in the graph which I really cant explain as the application was idling and there were no user interaction of an kind. (I did not wait for reaching the 3G limit but the trend is clearly visible.)

I tried checking couple thing, but so far I was unable to identify the source of the problem. I the performance and memory profiling tool (results attached as a txt as well as an xlsx), but I dont see anything really consuming too much memory.

Any ideas about or clues?

Thanks!

(using labview 2022 Q3)

[GerdW]

Hi 1984,

---

@1984 wrote:

The problem also affects the uncompiled code.

---

When you execute code then it is always compiled.

LabVIEW always compiles under the hood!

The problem is in your source code. As long as you don't show the code we cannot do the debugging for you...

[PinguX]

Hi 1984,

As GerdW said it is nearly impossible to say what's wrong until we can look at your code.

Can you try again after disabling this VI :

Framework_main.lvlib:Logger2.lvlib:LOG Format Log Message.vi

Or even all functionalities under "Logger2.lvlib".

I'm curious about your logging. It looks like you use it rather intensely.

[1984]

Yes, its always a catch 22. I can not post my project as it is full with IP and without posting it its practically impossible to provide help. But anyways even if I could share it, debugging even a smaller project could take many hours, which nobody ever want to do in his 5 minute forum time.

The logger module was that active because for debugging I logged the memory consumption 2-3 times in a second. Shutting that down did not affect the "leak".

At this point I think I identified the problematic modules which - luckily - I can completely shut down right after I launch my application as they are mostly there for convenience and they dont affect the core functionality of the application.

I dont understand though whats wrong with those modules, cause at the first sight they look OK to me. If I cant figure out than I will post these with source code to the DQMH forums.

[billko]

3 GB is when most 32-bit applications will start running out of memory, but beyond that I have no idea what may be making your memory grow.

[Kyle97330]

I mean, without code it's impossible to help directly, and even with it on a big application it wouldn't be easy.

What you really need to look at is the few types of places that usually cause continual growth:

1. Arrays (or other potentially limitless data types, like matrices, maps, sets, etc.)

Look over every VI that uses these.  You are looking for something that could be an array that both grows (i.e. not a fixed size) and could potentially be maintained in memory (for instance, an array in a global variable, located on your main VI, or stored in a shift register/feedback node on an often used VI, etc.)

2. Un-emptied lossless data streams (queues, event registrations, etc.)

If you generate a queue reference and enqueue elements into it but then don't dequeue them all or destroy it, those elements stay in memory forever.  Similarly, if you have an event registration that is created but then the events aren't handled and the registration isn't destroyed, they can stay in memory forever.

3. Cloneable VIs that don't end properly

If you use cloneable VIs, notably ones that you run asynchronously, if they don't terminate you can end up with far more copies running than you expect.  Or, if they do terminate but you have them set as "call and collect" but don't perform any collection or otherwise close the reference later, they just hang around in memory.

Those are the main broad categories I can think to check.  There might be others...

[1984]

Thanks everbody for responding. I didnt pay too much of an attention of how the graph looks like I just considered that the memory need is increasing. But if you look carefully its stairstepping. The steps take about 90 samples and as the query was made in about every 300ms one flat region lasts for about 30s and then increases.

The modules I disabled take action in every 30s so I'm about 99.43% sure that they are responsible for the issue and I'm also almost positive that somewhere - over the rainbow - I forgot to close at least one reference. I will investigate this issue later, and as mentioned I will post it on the DQMH forums.