Mark Bixby wrote:


> I've been asked how you can determine if a process might have a memory leak.
> ....
> ...Over time, this allocated but
> unused memory can add up to system performance degrading levels....
> ...
> So my question remains: how can I tell the total size of all memory allocated
> to a process, especially malloc()-ed memory?


Regarding Performance: this isn't really an issue given the way that MPE/iX is
designed:
What does malloc() really do?   "C" does some internal bookkeeping but
basically
malloc() grabs a Virtual Address Range from the user's stack area which
contains
the HEAP.    Notice that I said Virtual Address Range as such no REAL memory
pages are allocated until the Virtual Page is actually touched. The beauty of
MPE/iX Virtual Memory is that data on REAL pages that are not recently touched
is
gradually swapped to disk leaving room for useful information.   So if a
program
'loses' some of its own heap due to careless management it will effect
performance very little in the long run.  In additional since this is a process
private resource one process' mismanagement of its heap doesn't affect any
other
processes directly.   (Yes, large Virtual Stack/Heap Objects are slightly more
expensive to manage but on a system level this is just noise.)  The other
advantage of this is that when this process terminates any REAL memory that was
part of the HEAP is returned to the global pool (unlike what can happen on a PC
or some UN*X systems).  Note that this is actually true for ALL types of memory
allocation for User Programs including SVIPC shared memory, Short and Long
Mapped
Files and even CM DSTs; all of these are Process Objects that are released when
a
process dies and who's pages are only in REAL memory when actually being
referenced.

If you're running out of HEAP space and you want to get a clue as to what the
problem is figuring out what is actually taking up the space there isn't an
easy
way that I know.  "C" malloc() gets space from the NM Heap.   Stan mentioned
the
PIBX.heap_base field previously: "C" starts at PIBX.heap_base and "grows"
towards  higher addresses.  Pascal NEW() and getheap() get space from the NM
Heap
too. Pascal starts at PIB.heap_limit and  "grows" towards lower addresses.
The
compiler libraries draw a line between the two to prevent the possibility of
walking on each other.   I suspect that "C" and Pascal each maintain bit-maps
of
what they've actually allocated.  However I don't have that information AND
it's
likely HP confidential anyway so I couldn't post it.  You could try using
PM Debug to display the contents of these memory areas but unless you
understand
how "C" and Pascal account for the space it will be very hard to tell the
difference between free()'d space and "lost" space.

Jim Hawkins
My mistakes and opinions not my employer's; YMMV ;->