Kbase P47400: How to check for memory leaks with COM automation objects ?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/20/2009 |
|
Status: Verified
GOAL:
How to check for memory leaks with COM automation objects ?
GOAL:
How to troubleshoot COM / ActiveX Automation issues ?
FACT(s) (Environment):
Progress 9.x
OpenEdge 10.x
Windows
FIX:
COM automation objects (= objects used to interface with a third-party application such as Excel) are built in such a way that the main code for the objects (= the required components of the third party application) is only run once.
This is managed by a reference count - basically each reference will increase the count, and as long as the counter is higher than zero the automation object (and attached processes) is kept in memory. In turn, this will provide improved performance if multiple instances of the object are used within one or more applications.
This means that each COM handle created for the automation will increase the reference count, and any handle that is released will remove it. If the last handle is removed, the automation will be removed from memory.
To track if the automation is kept open longer than expected:
First check to see if the 3rd party application accessed via COM automation has any processes running at unexpected times. This indicates objects not being released properly, as this means the reference count is not zero.
The second step is to double-check the code that interfaces with the 3rd party application. Make sure all the RELEASE OBJECT statements are there, keeping in mind that this includes COM-HANDLES received as parameters and such, not just the ones explicitly created in the 4GL code.
Be wary of re-using COM-HANDLE variables for this reason - reusing a COM-HANDLE without releasing first will result in orphaned com-objects which in turn will keep the 3rd party application in memory.