Did this article resolve your question/issue?



How to detect ABL Memory Leaks with Dynamic Objects Logging

« Go Back


TitleHow to detect ABL Memory Leaks with Dynamic Objects Logging
URL NameP133306
Article Number000128464
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
Files 1.
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.