Application walks SESSION:FIRST-OBJECT tree and detects object that should have been deleted

Application detects memory leaks by walking through the SESSION:FIRST-OBJECT tree.  
More than one instance of an object is detected when there should only be one object in use leading to the memory leak
When more than one instance of an object is detected identifies the leak but not what is causing it
 

Code similar to the following scans the SESSION:FIRST-OBJECT chain to determine if the expected object to be collected is there when it shouldn’t be.  

METHOD PUBLIC LOGICAL IsAlive(INPUT piRef AS INT): 
  DEF VAR lAlive AS LOG. 
  DEF VAR objRef AS OBJECT. 

  objRef = SESSION:FIRST-OBJECT. 
  lAlive = NO. 
  DO WHILE VALID-OBJECT(objRef) AND NOT lAlive: 
    lAlive = INT(objRef) EQ piRef. 
    objRef = objRef:NEXT-SIBLING. 
  END. 
  RETURN lAlive. 
END METHOD. 

The utility which scans the SESSION:FIRST-OBJECT chain, would need to use an integer representation of the object reference being searched for,to avoid the act of looking causing the object not to be collected.

Using the LOG-MANAGER system handle, it was determined that a logic flaw in the application code allowed multiple instances of the class to be instantiated and retained in memory.

Use the LOG-MANAGER system handle to determine where objects are created and deleted, then refer to the programs and line numbers shown in the trace log to isolate the flaw in the application logic.

To generate a trace log containing object creation and deletion information:

LOG-MANAGER:LOGGING-LEVEL   = 4.
LOG-MANAGER:LOG-ENTRY-TYPES = "DynObjects.Class".
LOG-MANAGER:LOGFILE-NAME    = "SomeFileNameGoesHere".

The resulting log file will contain a line for each creation and deletion.  
Each line will give a program and line number where the creation/deletion took place.

The output from using LOG-MANAGER can also be achieved using 4GLTrace and DynObjects.* client logging if a session-wide trace log is required:

prowin -clientlog SomeFileNameGoesHere -logginglevel 4 -logentrytypes DynObjects.Class

For more detailed information on checking for memory leaks with dynamic objects please refer to the following Article:

Progress Article:
Identifying and Troubleshooting Memory Leaks