How I can monitor the HEAP memory of a process ( c++) on Guardian Environment

[francisco lopez]

Hi all, I am writing to perform the following question:

My program written in c++ have problems with extended memory heap.


What is the way to know the use of the heap for a process?

I'm working on integrity Machine.

thanks you

[Robert Hutchings]

Check the HEADROOM_ENSURE_ Guardian Procedure.

http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02543407-5.pdf

[wbreidbach]

Am Dienstag, 14. Januar 2014 20:15:19 UTC+1 schrieb Robert Hutchings:
> Check the HEADROOM_ENSURE_ Guardian Procedure.
>
>
>
> http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02543407-5.pdf

I think the question is what you want to do. Do you want your process to minotor its own heap or are you looking for a tool to monitor the heap from the outside? There are several tools available to do it from the outside,In fact we ourselves have created one of those tools. If that is what you are looking for, I can send you a time-limited testversion.

[Keith Dick]

What kind of problems are you having? Is the heap getting corrupted and you are getting errors about that? Or are you getting errors due to the heap getting full and you cannot allocate more space?

If your problem is heap corruption, the library function heap_check_always() can be used to make the heap routines check the consistency of the heap on every call that allocates or deallocates memory from the heap. It won't tell you exactly where in your program that heap corruption is happening, since that generally happens between calls to heap management routines by storing using an out-of-date pointer or a pointer whose value has been calculated incorrectly, but it probably will help you identify more closely the part of your program in which the bad pointer is being used. I believe some of the heap management capabilities documented in the CRE Programmer's Guide could also be of help. There is a way to get the heap manager to rewrite space that has been freed with 0xFFFC3C3C, which might make it more obvious if your program is using data from memory that has been freed.

If your problem is using too much heap space, it probably is forgetting to release memory when that memory no longer is needed -- what's commonly called a memory leak. What you'd really like to have to debug such a problem is an option to make the runtime library allocate a little extra memory in each block it allocates and record in that extra memory something about where in the program the memory was requested, then on request or on terminating the program, the library should write a report saying how many blocks were still allocated from each point in the program. I don't know of an option to do that. I have a vague memory of being told about a way to get such reports, but that might have been for another computer system -- the memory is very vague. Such a debugging feature would seem to be so useful that I wouldn't be surprised to learn that it exists, but I do not know that it does.

There is a function in the CRE that can retrieve a number of statistics about the current size of the heap, number of blocks allocated, and total amount of space allocated. You could call that function at various points in your program and report the results so you could see how heap use is changing. I think that would not be nearly as useful as knowing the number of blocks allocated from each point in the program, but at least it can tell you a little about the program's heap usage.

All these CRE functions I mentioned are described in the CRE Programmer's Guide, in section 2, under the heading "Using the Native Heap Managers".

If I remember correctly, the PSTATE program includes some information about heap usage among the many things it reports about a process. If your program is running out of heap space, and takes a while to get to the point where that happens, you might be able to use PSTATE to get a rough idea of its heap usage and how that changes, but I kind of doubt what PSTATE can show would be very helpful for this problem.

I see that Robert suggested looking at the Guardian procedures HEADROOM_ENSURE_. That procedure is concerned with stack space, not heap space, and so it probably will not help you with your problem.

[Robert Hutchings]

I think we need more info from OP. Please try to give us more details when posting questions...this way we can "drill down" to your issue or question faster and with less ambiguity.

[wbreidbach]

Am Mittwoch, 15. Januar 2014 01:19:19 UTC+1 schrieb Robert Hutchings:
> I think we need more info from OP. Please try to give us more details when posting questions...this way we can "drill down" to your issue or question faster and with less ambiguity.

The correct procedure is PROCESS_GETINFOLIST_, it provides all the needed information.

[wbreidbach]

Just to complete the information: The items are
111 current size of native heap area
112 maximum size of native heap area
151 current size of the 64-bit heap area
152 maximum size of the 64-bit heap area

[Keith Dick]

The routines described in the CRE manual that I mentioned earlier seem to give more information than these items seem to provide. For example, one of the items the CRE can provide is the count of blocks on the free list. This could give some indication of the amount of fragmentation, which you could not get from the PROCESS_GETINFOLIST_ results. Also, the CRE documents one of its items as the sum of the sizes of all the blocks on the free list. I'm not sure that matches any of the results PROCESS_GETINFOLIST_ provides.

[wbreidbach]

The main question goes to the OP's intention: Change the program or check from the outside. The CRE rotuines require changing the program, PROCESS_GETINFOLIST_ can be used from the outside.
The first and easiest thing to do would be using PSTATE <process>, STA. This will provide information about the actual stack and heap usage and the available stack and heap.

[Robert Hutchings]

Perhaps you could use Google Translate if English is not your native language. We want to help you but we are not sure what you are asking...

[francisco lopez]

thanks you Keith, I am very grateful for your help, it helped me a lot.

the "PSTATE" command is what I really needed.

the problem of the memory leak fix adding delete statement.

I just wanted to see a graphical way, was happening with memory.

thanks you,

Francisco