How can i detect "Memory leak" with large LabVIEW projects.

[Bdev]

Hi,

I have a huge LabVIEW application that runs out of memory after running continuously for some time. I am not able to find out the VI that is hogging up memory. Is there any tool that dynamically detects the VI that is leaking memory.

Or, is there a tool or a way to identify the critical areas which can be potential culprits that is leaking memory.

Regards

Bharath

[Wayne.C]

Bdev,

Have you tried Tools»Profile»Performance and Memory ?  https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/dialog-boxes/profile-performance-and-memor...

[Coq_Rouge]

Very often a suspected memory leak, is not a leak. But memory misuse caused by the programmer. But the tip from Wayne.C will help you to find the source of your problem

[Dennis_Knutson]

There is the Desktop Execution Trace Toolkit.

Since your user name is 'blue', that means you work for NI and should have access to this toolkit.

[smercurio_fc]

---

Dennis Knutson wrote: 

Since your user name is 'blue', that means you work for NI and should have access to this toolkit.

---

The forum software is broken with respect to this. It often identifies non-NI people as NI people. It has yet to be fixed.

[Dennis_Knutson]

Yeah, I know. I just wish the misidentified people would request their status to be changed. I think all it would take is a 'Report to Moderator'.

[Bdev]

Thanks Dennis.

I think Desktop Execution toolkit should solve the problem. 

Wayne Wrote

---

Have you tried Tools»Profile»Performance and Memory ?  https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/dialog-boxes/profile-performance-and-memor...

---

But this will just give me the amount of memory used by the VIs and not the amount of memory that is not getting released.

[rolfk]

---

Bdev wrote:

Thanks Dennis.

I think Desktop Execution toolkit should solve the problem. 

Wayne Wrote

---

Have you tried Tools»Profile»Performance and Memory ?  https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/dialog-boxes/profile-performance-and-memor...

---

But this will just give me the amount of memory used by the VIs and not the amount of memory that is not getting released.

---

And where is the problem about that? Just try to find what VIs keep increasing in memory size. That are the culprits. If you have real memory leaks, meaning there is memory that is not managed by LabVIEW directly but for instance by a DLL somewhere and that DLL looses references to memory, so it goes really lost, then the only way to find that is by successively exclude functionality in your application until you can find the culprit.

There is no other simple way to find out about who is loosing memory references than by doing debugging by exclusion until the problem disappears. The only way to speed this up, which quite often works for me is doing an educated guess, about what components are most likely to do this misbehaviour.

Not knowing anything about your application and if you are talking about memory hogs (fairly easily identifiable by the mentioned Performance and Memory monitor) or actual memory leaks, it is hard to tell how to go about it. Memory hogs are usually the first thing I suspect escpecially with software I inherit somehow from people from whom I'm not sure they know all the ins and outs of LabVIEW programming.

If a leak seems likely the first culprit usually are custom DLLs (yes even DLLs I have written myself), then NI DLLs such as DAQmx, etc. and last there come leaks in LabVIEW itself. This last category is very seldom but it has happened to me. However before going to scream about LabVIEW having a memory leak you really, really should make sure you have very intensivly researched all the other possibilities. The chance that you run into a memory leak in LabVIEW, while not impossible, is so small compared to the other ways of causing either a memory hog or running into a leak in an external component to LabVIEW, that in 99.9% of the cases where someone screams about a LabVIEW memory leak, he is simply wrong.