memory occupancy

[fabio grasso]

Hi. My application, in debug mode, increases continuously the memory load. How can I monitor all variables loaded, in a particular moment, and their size?

[jr_2005]

Sounds like you are allocating memory in some program loop, without freeing it once you have finished with it. I'm not sure that monitoring all the variables would lead you to a solution; just inspect your code carefully and ensure that each malloc() (or calloc(), or equivalent) has a matching free().

JR

[DaveC]

Fabio,

Check out this post http://forums.ni.com/ni/board/message?board.id=180&message.id=17428

specificially LuisG (NI engineer) message:

"LabWindows/CVI has its own internal memory manager which is used to manage memory allocation requests that come from inside CVI (such as from UI controls). This memory manager obtains memory from the system in chunks, as needed, but doesn't always return memory to the system as soon as it becomes available (it has some fairly complicated logic for when it should return memory to the system, mainly for performance reasons).
 
So what you are seeing is that even though the list control has freed up its memory when you remove all those items, and the memory is now free as far as the CVI memory manager is concerned, you cannot see this "freed memory" using the Windows Task Manager. However, if you were to request another large allocation after freeing these items, you should notice that CVI will not need to allocate additional memory from the system.
 
Basically, a good rule of thumb, when you suspect a memory leak somewhere, is to put the action that you are suspicious of in a loop. Do it 100 or 200 times, and see if you are gradually losing memory from the system. If you are, then there is a memory leak. If not, then there is probably no leak. It's just that a lot of allocations take place on an "as needed" basis, so things don't always return to their pristine state after a single create/discard iteration.
 
Luis
NI"

This may explain the problems you are having.  I have seen the same thing happen in my CVI programs as well.

[jr_2005]

Dave,

Although this could explain why CVI internally freed memory may not immediately be visible when viewed with Windows Task Manager, it doesn't actually address the problem of the apparant memory leak which was originally described, where memory usage continually increases with execution time. When you say you see the same things happen in your CVI programs, do you mean you get memory leaks or simply that memory appears not to be returned to the OS? I have some pretty big programs which run continuously and have never seen any memory leaks.

JR

[LuisG]

Fabio,

Besides the suggestions that have been made so far, I should also point out that there is a function in the CVI utility library, called CVIDynamicMemoryInfo, that will help you monitor memory usage. However, you should keep in mind that there are many ways in which your program could be leaking memory/resources. The most obvious is by having mallocs that are not freed, and this function will help you with that. However, there are lots of other objects that your program could be leaking that would not show up as a memory allocation -- yet they will eventually cause you to lose memory. These include UI objects, such as menus, controls, bitmaps, etc. They also include handles that are used in libraries such as the ActiveX library, the Internet library, etc. My advice is to start with the dynamic memory function, and if that doesn't show anything unusual, yet you are still leaking memory, you will then need to start isolating chunks of your code and look for continuously increasing memory usage in those code segments. Hopefully it will become apparent after a while.

Luis

[DaveC]

Hi JR,

What I've seen is memory that isn't returned to the OS.  For instance, I have an application that I typically run through the entire day every day and shut down at night.  It runs a process every 10 seconds.  What I've seen (from task manager) is that it will grab maybe a couple megs of memory initially over the first hour or so and then it will very rarely surpass that initial couple meg memory threashold.  It will just hover around there.  Which, looking back on the original post, you are right this behavior isn't really what fabio was seeing.  I guess it's back to checking mallocs