Kbase P124514: How to check for leaked dynamic objects?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
17/02/2011 |
|
Status: Verified
GOAL:
How to see what structures are being left in memory when running applications?
GOAL:
How to check for dynamic objects that are being left in memory?
GOAL:
4GL Code to help determine if resources are not being cleaned up within an AppServer procedure.
GOAL:
What objects are being left in memory by an application?
GOAL:
4GL Code to help determine if resources are not being cleaned up within an WebSpeed Agent procedure.
FACT(s) (Environment):
OpenEdge 10.x
All Supported Operating Systems
WebSpeed
FIX:
/*
Description - Simple program to walk the widget trees that the 4GL
makes available and dump out some basic information
on the objects which have been left in memory.
This should be used in conjunction with the new Java
based debugger to look for and fix memory leaks.
This code uses the MESSAGE statement to ensure that
when run on the AppServer the results will be available
in the AppServer server log file (assuming, of course,
that the loggingLevel is set to either Verbose or Extended).
The code inside of each DO WHILE block can be changed into
the appropriate DELETE statement in order to make this
program into a quick & dirty tool to release leaked
resources on the AppServer so that the AppServer does
not have to be shut down and restarted. Just make the
code change then from a 4GL client run this program
on the AppServer.
When debugging memory leaks on the AppServer it is best
to take the AppServer out of the picture (for easier
debugging). To do this just create a simple program
in the Procedure Editor similar to the following:
RUN Some_Problem_Program (... Parameters ...).
PAUSE.
&n.bsp; Select Compile/Debug from the menu and before you do
anything else tell the debugger to monitor all of the
objects that it knows how to monitor. Set a breakpoint
on the PAUSE statement then tell the debugger to 'Run'.
When the code is finished and you are sitting at the
PAUSE statement flip back to the debugger and look
at what objects the debugger says are still in memory
and start analyzing what coding flaw has left the objects
in memory and fix the flaws.
Please note that this code was designed to work on
OpenEdge 10.x platforms. To use this code with
previous versions you will need to remove the DO/END
blocks that reference SESSION attributes that do not
exist in your version.
*/ DEFINE VARIABLE hTemp AS HANDLE NO-UNDO.
DEFINE VARIABLE hObject AS HANDLE NO-UNDO.
DEFINE VARIABLE vTemp AS CHARACTER NO-UNDO. ASSIGN hObject = SESSION:FIRST-DATASET.
DO WHILE hObject <> ?:
ASSIGN hTemp = hObject
hObject = hObject:NEXT-SIBLING.
MESSAGE 'ProDataSet, Handle=' hTemp
', Name=' hTemp:NAME
', Dynamic=' hTemp:DYNAMIC VIEW-AS ALERT-BOX.
END. ASSIGN hObject = SESSION:FIRST-DATA-SOURCE.
DO WHILE hObject <> ?:
ASSIGN hTemp = hObject
hObject = hObject:NEXT-SIBLING
vTemp = (IF hTemp:QUERY = ? THEN ? ELSE hTemp:QUERY:PREPARE-STRING).
MESSAGE 'DataSource, Handle=' hTemp
', Name=' hTemp:NAME
', Query=' vTemp VIEW-AS ALERT-BOX.
END.. ASSIGN hObject = SESSION:FIRST-BUFFER.
DO WHILE hObject <> ?:
ASSIGN hTemp = hObject
hObject = hObject:NEXT-SIBLING.
MESSAGE 'Buffer, Handle=' hTemp
', Name=' hTemp:NAME
', Table=' hTemp:TABLE
', Dynamic=' hTemp:DYNAMIC
', DataSet=' hTemp:DATASET VIEW-AS ALERT-BOX.
END. ASSIGN hObject = SESSION:FIRST-PROCEDURE.
DO WHILE hObject <> ?:
ASSIGN hTemp = hObject
hObject = hObject:NEXT-SIBLING.
MESSAGE 'Procedure, Handle='hTemp
', Name=' hTemp:NAME VIEW-AS ALERT-BOX.
END. ASSIGN hObject = SESSION:FIRST-QUERY.
DO WHILE hObject <> ?:
ASSIGN hTemp = hObject
hObject = hObject:NEXT-SIBLING.
MESSAGE 'Query, Handle=' hTemp
', Name=' hTemp:NAME
', Dynamic=' hTemp:DYNAMIC
', Query=' hTemp:PREPARE-STRING VIEW-AS ALERT-BOX.
END. .