Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025



How to detect ABL Memory Leaks with Dynamic Objects Logging

« Go Back


Article Number000012302
EnvironmentProduct: OpenEdge
Version 10.x, 11.x
OS: All supported platforms
Question/Problem Description
How to detect ABL Memory Leaks with Dynamic Objects Logging
How to find out if a memory leak is caused by ABL dynamic objects not being managed correctly ?
How to verify if dynamic objects are deleted correctly using the extended logging facilities ?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
In OpenEdge 10.0B the DynObjects log entry type was introduced.  This logging feature allows all Dynamic objects created and deleted in a OpenEdge session to be logged

This feature is used by specifying one or more of the following after the -logentrytypes parameter or by setting the LOG-ENTRY-TYPES attribute of the LOG-MANAGER handle.
  • DynObjects.Class
  • DynObjects.DB
  • DynObjects.Other
  • DynObjects.XML
  • DynObjects.UI

DynObjects.* can be used to include all of the above.

Example for an ABL client process (WebClient, GUI client, ChUI client): 
-clientlog <logfilename> -logentrytypes "DynObject.Class,DynObjects.UI" -logginglevel 3

For WebSpeed/AppServer Agents, the same log entry types and logging levels can be specified in the server logging settings. All Dynamic objects created and deleted will then be written to the *.Server.log logfile.

Once output is generated, it can be analyzed using the logread utility or by simply reading the file and matching up all the creates with all the deletes.

Logs will show one of the following patterns:
  1. For a given handle number, both a "Created" and "Deleted" entry for the number indicates that the Object has been cleaned up after use.
  2. For a specific Object, there is only a single "Created" entry (or a limited, predictable number) for that particular object in the lifetime of the session. This is often seen when the same Object is being re-used multiple times, for example, with persistent procedures for which a single instance is used multiple times as a super procedure.
  3. Anything else is a likely object leak which requires further investigation.
The attached provides an example procedure to parse the log entries generated; it will report any "Created" entry that does not have a matching "Deleted" entry, along with where in the code the create happened. 

leakcheck.p - to parse the log files generated on the clients, WebSpeed agents, Classic Appserver agents

For .NET objects, client logging can only track the ABL side. This will not show anything for .NET objects that are not referred to on the ABL side. A .NET control may use several sub-objects. If there is never a reference to one of these subobjects on the ABL side, it will never show up in the client log.

Please note that in a development environment the tools can clean up objects in a way that gets logged. This can potentially mask memory leaks.
Filtering out logging lines matching "*adecomm/_runcode.p*" can help to avoid this.
References to other documentation:

OpenEdge Development Tools: Debugging and Troubleshooting, chapter Logging in OpenEdge

Progress Articles:

000011782, How to check for leaked dynamic objects programmatically?  
000084455, Detect PASOE memory leaks with Dynamic Objects Logging  
000021724, How to find a memory leak?  
000022577, Managing Memory within the ABL?  
Last Modified Date9/30/2019 9:21 AM