Tracking of All Handles – Memory Level

Hello All,

I am trying to catch all dynamic objects (handles) in server memory (UNIX), memory walkthrough. I thought to create one script to list all handles (Progress) available in memory and depending on certain condition, delete that handle.

I created one small dynamic query program and I used pause statement before DELETE OBJECT statement. I checked in “TOP” (UNIX command) but didn’t find any relevant process.

Please provide any clue/suggestion on this please.



Active Member
You want to delete handles in the AVM from outside the AVM?
From within the AVM you can trace handles using session:first-* and :next-sibling
Thanks for your valuable response Stefan!

As per my understanding, handles remain in memory when created and persist there until we delete them by using DELETE OBJECT.

If handle is not deleted and created again then previous handle remains in memory and could cause memory leakage issue. Form memory, I think its server memory (RAM).

I just want to walk through the memory and list down all available handles there.

Please suggest if it is possible or not, if yes then kindly give me some directions on how to achieve this.


Active Member
The following is just for query handles, a similar concept applies to all dynamic objects using session:first-<object-type>:
// main.p

def var hq as handle no-undo.
def var hqdel as handle no-undo.

run leak.p.

hq = session:first-query.
do while valid-handle( hq ):
   hqdel = hq.
   hq = hq:next-sibling.
   if hqdel:instantiating-procedure = ? then do:
      message 'deleting' hqdel.
      delete object hqdel.
// leak.p

def var hq as handle no-undo.

create query hq.
create query hq.
Last edited:

Cringer Moderator
Staff member
It's still much better to handle cleanup of your handles specifically, rather than a catch-all like this. You could very easily clean up something unintentionally.
A much better belt-and-braces approach is to add an unnamed buffer pool to each .p. When you create handle based objects they will then get added to this pool. When the .p goes out of scope the pool is then removed, along with everything scoped to it. That way you know that only handle based objects that are scoped to a procedure get deleted rather than inadvertently removing things like super procedures you may actually still need.
But, that said, it's still better to clean up after yourself explicitly.
I appreciate all suggestions!

Yes, I agree that we have other solutions like Log-Manager, Widget pool to manages handles.

I was thinking of all other approaches to handle dynamic object. One was memory walk through that i thought. It is pretty interesting if we can check complete memory and find all dynamic Objects.

Please share your thoughts on this.


Rob Fitzpatrick Sponsor
You could also have a look at the Log Manager and log entry types, particularly DynObjects.*.

This subject is covered in the manual Debugging and Troubleshooting, Troubleshooting Resources, Log Entry Types Detail, Dynamic object logging.