Simplest way to detect memory leak?

[TG]

Whats the simplest way to detect a possible memory leak in LabVIEW?

thx

[Yair]

The question is very general and would depend on the nature and manifestation of the memory leak, but usually, a reasonable way of finding what's causing something is to place case structures on parts of the code and then enable and disable those parts as needed.

Things which are usually liable to cause memory leaks are resizing operations in loops (e.g. Build Array, Concat Strings) and opening references without closing them.

[Tim Erickson]

Use Windows Performance Monitor. Select "Process" in the Performance Object control. Then select "Page File Bytes" in the Counters List control. Then select "LabVIEW" (or the name of your LabVIEW executable) in the Instances List control. Add this to the graph and watch it over time while your vi is running. If graph trends up, you have a memory leak.

If you do have a memory leak, look for instances where you open a reference without closing it over and over (queues, vi ref's, notifiers, etc.).

Tim

[Mark Smith]

QUOTE (Tim Erickson @ Jan 8 2009, 02:31 PM)

Use Windows Performance Monitor.

Assuming you're on Windows, the Performance Monitor is a good start but to get more detailed info go to

http://technet.microsoft.com/en-us/sysinte...s/bb896653.aspx

and get the Process Explorer app - you can get detailed info on any process on your system including memory usage.

[SimonH]

You could also use the VI Profiler that can be found at Tools » Profile » Performance and Memory…. If you check "Profile memory usage" it will show you the memory being used by each running VI as your program runs.

[jdunham]

QUOTE (SimonH @ Jan 8 2009, 02:11 PM)

You could also use the VI Profiler that can be found at Tools » Profile » Performance and Memory…. If you check "Profile memory usage" it will show you the memory being used by each running VI as your program runs.

No, there are plenty of things the profiler won't report. I don't believe that shows global memory like queues and notifiers or stuff allocated by ActiveX nodes that you've invoked.

[SimonH]

QUOTE (jdunham @ Jan 8 2009, 04:52 PM)

No, there are plenty of things the profiler won't report. I don't believe that shows global memory like queues and notifiers or stuff allocated by ActiveX nodes that you've invoked.

Good point -- the profiler isn't an exhaustive tool but it's probably worth knowing about. I suppose I use it more for performance optimization than for hunting down memory leaks.

[Phillip Brooks]

QUOTE (jdunham @ Jan 8 2009, 05:52 PM)

No, there are plenty of things the profiler won't report. I don't believe that shows global memory like queues and notifiers or stuff allocated by ActiveX nodes that you've invoked.

Creating an unlimited sized queue in LabVIEW (or in ANY programming language for that matter) is BAD MOJO!

http://lavag.org/old_files/monthly_01_2009/post-949-1231501591.gif' target="_blank">

[OlivierL]

QUOTE (Yair @ Jan 8 2009, 12:26 PM)

Things which are usually liable to cause memory leaks are resizing operations in loops (e.g. Build Array, Concat Strings) and opening references without closing them.

About the Build Array and Concat Strings, isn't LabVIEW supposed to release the memory automatically by itself after the loop is over? I can see that as taking huge amount of time in a long loop process but can memory leaks really happen from that?

Olivier

[jdunham]

QUOTE (OlivierL @ Jan 13 2009, 09:16 AM)

About the Build Array and Concat Strings, isn't LabVIEW supposed to release the memory automatically by itself after the loop is over? I can see that as taking huge amount of time in a long loop process but can memory leaks really happen from that?

You're basically right, depending on your definition of memory leak. LabVIEW itself isn't leaking memory if it's just doing what you ask. But if performance slows to unacceptable levels while the loop is running, and maybe if that's what the OP is experiencing, then he would be advised to look for these situations.

[Rolf Kalbermatter]

QUOTE (OlivierL @ Jan 13 2009, 12:16 PM)

About the Build Array and Concat Strings, isn't LabVIEW supposed to release the memory automatically by itself after the loop is over? I can see that as taking huge amount of time in a long loop process but can memory leaks really happen from that?

Olivier

Build array can not cause a memory leak in the true sense of the word. A memory leak means really that memory got allocated and the reference got lost somehow without the memory being freed. The unlimited Build Array function is really just a memory hog meaning it will accumulate memory over and over without ever releasing it. It is not a memory leak in the sense that LabVIEW very well knows about it and will eventually release it if you unload the VI containing that huge accumulated array.

QUOTE (jdunham @ Jan 8 2009, 05:52 PM)

No, there are plenty of things the profiler won't report. I don't believe that shows global memory like queues and notifiers or stuff allocated by ActiveX nodes that you've invoked.

Not sure about queues really. It might not track them. For memory allocated in external components like ActiveX servers or even DLLs the Profiler has no way of tracking that down really as it is not allocated under its control.

Rolf Kalbermatter

[Antoine Chalons]

QUOTE (rolfk @ Jan 14 2009, 10:14 AM)

Build array can not cause a memory leak in the true sense of the word. A memory leak means really that memory got allocated and the reference got lost somehow without the memory being freed. The unlimited Build Array function is really just a memory hog meaning it will accumulate memory over and over without ever releasing it. It is not a memory leak in the sense that LabVIEW very well knows about it and will eventually release it if you unload the VI containing that huge accumulated array.

I think we have to separate memory leaks like defined by Rolf (memory got allocated and the reference got lost somehow without the memory being freed) and http://eyesonvis.blogspot.com/2008/07/memory-lakes.html' rel='nofollow' target="_blank">memory lakes which can be caused by uncareful use of the build array function.

The way to detect memory leak and memory lakes are not exactly the same. I faced both. Memory leaks are annoying but once you've found out which reference is not freed correctly you can find a work-around. Memory lakes in a fairly big application (about 2k VIs) are really not easy to fix. In my case the memory used by the application was stable for about 30 hours and then started to slowly increase untill breaking the 2 Go limit and resulting in a crash.

Since you don't always explicitly allocate memory in LabVIEW programming you need to learn how LabVIEW will allocate its memory and code your application appropriately. Learning this was time and energy consuming for me because I have no background in C (or any other language) but it was really worth, now I feel a lot more confortable in my day to day coding.

Doing this might not be a "simple way" to detect memory leaks or memory lakes but this is the way I recommend. There are many good white papers on NI knowledge base regarding memory managment.

[Yair]

Correct you are. The funny thing is that I commented on Christina's post back when it was new saying that this distinction was important and that I'll remember it for next time. Then, of course, I promptly forgot about it.

[ragu]

QUOTE (Antoine Châlons @ Jan 14 2009, 09:40 AM)

I think we have to separate memory leaks like defined by Rolf (memory got allocated and the reference got lost somehow without the memory being freed) and http://eyesonvis.blogspot.com/2008/07/memory-lakes.html' rel='nofollow' target="_blank">memory lakes which can be caused by uncareful use of the build array function.

The way to detect memory leak and memory lakes are not exactly the same. I faced both. Memory leaks are annoying but once you've found out which reference is not freed correctly you can find a work-around. Memory lakes in a fairly big application (about 2k VIs) are really not easy to fix. In my case the memory used by the application was stable for about 30 hours and then started to slowly increase untill breaking the 2 Go limit and resulting in a crash.

Since you don't always explicitly allocate memory in LabVIEW programming you need to learn how LabVIEW will allocate its memory and code your application appropriately. Learning this was time and energy consuming for me because I have no background in C (or any other language) but it was really worth, now I feel a lot more confortable in my day to day coding.

Doing this might not be a "simple way" to detect memory leaks or memory lakes but this is the way I recommend. There are many good white papers on NI knowledge base regarding memory managment.

hi,

i have 1 year experience in labview.i want to know how labview allocates the memory(i.e. internals of labview).could you please give some tips or answers to learn.

thanks in advance...

[Rolf Kalbermatter]

QUOTE (ragu @ Feb 3 2009, 12:10 AM)

hi,

i have 1 year experience in labview.i want to know how labview allocates the memory(i.e. internals of labview).could you please give some tips or answers to learn.

thanks in advance...

This is not a simple topic. The right answers for you will depend on how much you already know about LabVIEW, C programming, OS details etc. Also the information is out there. There are several good Knowledge Base or Application Note articles on www.ni.com that have lots of details in these respects. Some of them go to details you will only want to know if you have a really sound understanding of how memory management is done in C programs.

The WIKI here on LAVA has also some good information which is not as in depth but should be good for an average LabVIEW programmer.

Go to events like LabVIEW days, or User Group Meetings. There are often presentation about advanced topics with LabVIEW such as how to make a good performing application versus a bad one which is also dependent on some basic understanding about LabVIEW memory management.

Go and search for this info and come back when you have more specific questions. We can not give you a 10 hour lecture about this topic here and it would not give you all the information that is possible anyhow.

Rolf Kalbermatter