HP3000-L Archives

February 2003, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Cadier <[log in to unmask]>
Reply To:
Bill Cadier <[log in to unmask]>
Date:
Wed, 19 Feb 2003 12:28:37 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (67 lines)
When you say "memory leak" are you referring to the typical "malloc/free"
type where something malloc's but never free's? Or are you seeing something
(I've never heard of) where something creates objects (via OS calls) and
sort of forgets to release them?

If it's the malloc/free thing it's a bit hard to diagnose having been there and
done that. The C library calls p_getheap to allocate a chunk of the MPE
process management heap. It then manipulates this chunk via code in the
C library. As I recall it has what are called "large block allocators" and
"small block allocators" which are linked lists of free areas in the chunks of
PM heap it has gotten. There isn't anything in the current debug macro set
to go off and check how the C library is using up these areas. There may
be programs that could do it. I have a program that I had to write that would
just watch a processes PM heap allocation. It doesn't prove a memory leak
but it helped indicate when one was occuring. The C library never returns
any of the PM heap it gets (afaik).

One trick is to set a debug break point at malloc() and then one at the RP
for malloc so you can get the pointer to the heap just malloc'ed. Then you
set a bp at free() and track what got malloc'ed and what got free'd. It is
*really* slow and requires some practice to set it up correctly and, of course
this only works if you can run the program in a safe environment where if
it decides to behave badly nothing bad comes of it.

If you are seeing what you think is a problem where a process is creating
MPE objects and not releasing them then that gets fairly involved. You can
determine if a process is creating SR5 objects but if they aren't it gets a bit
more difficult verging on impossible depending on when you check.

The debug macro to check the command history is ui_cihistory.

hth,

Bill
hp/vCSY

> Here's a tough one.
>
> I am suspecting a program of having a memory leak.  How do I prove it,
> other than the symptoms?
>
> Is there a way in DEBUG to determine how much memory a specific pin is
> currently using?
>
> Bonus question: when analyzing a memory dump, how do I view the command
> history of a session (process)?
>
> I know every one is busy formulating thier answers to the problems of
> the world, maybe this can help narrow the focus.  :)
>
> Regards,
>
> -Craig
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
> http://shopping.yahoo.com
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2