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
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
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:
- For a given handle number, both a "Created" and "Deleted" entry for the number indicates that the Object has been cleaned up after use.
- 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.
- Anything else is a likely object leak which requires further investigation.
The attached leakcheck.zip
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.