H
Henrique Berenguel
Guest
It would be great if during compile time the compiler code recognize and warn the developer about a potential part of the source code where dynamic objects (especially inside persistent procedures) were created but never deleted, so, this could be one of the potential causes of memory leaks that could be hard to identify and fix later on. Lets pretend the following client code (client.p) performs a PASOE APSV call to a server.p program and this server.p program also calls a srvMemLeak.p that will cause leaks (here intentionally). Along the development process, there's no way to figure out a memory leak threat was in the way, but that will cause considerable side effects in the PASOE server: client.p DEF VAR appHandle AS HANDLE. DEF VAR outName AS CHARACTER. DEF VAR cnctParam AS CHARACTER. DEF VAR ret AS LOGICAL. CREATE SERVER appHandle. cnctParam = "-URL http://localhost:7810/apsv". ret = appHandle:CONNECT(cnctParam). IF (ret) THEN DO: RUN server.p ON appHandle (INPUT 1, OUTPUT outName). appHandle
ISCONNECT(). END. QUIT. server.p: DEF INPUT PARAM customerNumber AS INTEGER. DEF OUTPUT PARAM customerName AS CHAR. DO TRANSACTION: RUN srvMemLeak.p PERSISTENT. END. FIND FIRST customer WHERE custNum = customerNumber NO-LOCK NO-ERROR. IF AVAILABLE customer THEN customerName = Name. ELSE customerName = "No record". ASSIGN customerName = "This is just another test...". PAUSE 10 NO-MESSAGE. srvMemLeak.p USING Progress.Json.ObjectModel.*. DEFINE VARIABLE hq AS HANDLE NO-UNDO EXTENT 1000. DEFINE VARIABLE lp AS MEMPTR NO-UNDO EXTENT 1000. DEFINE VARIABLE jo AS JsonObject NO-UNDO EXTENT 1000. DEFINE VARIABLE i AS INTEGER. DO i = 1 TO 100: CREATE QUERY hq. set-size(lp) = 50000. jo = NEW JsonObject(). END. So, here, it would have been great if during the compilation of the source code above the ABL compiler had alerted me about a potential source of memory leaks relsted to the srvMemLeak.p where many objects were instantiated but never been deleted. So, here for example, in PDSOE, you can see that I compiled the source code: (*right click the picture below and select to open in a new tab or browser so that the picture will get bigger) And here in the problems tab I got no warning at all: Sometimes, some ABL object definitions are done inside include files what will spread to many other programs increasing the severity of the problem. So, the idea was to have at least an warn message in the problems tab or in the ABL compiler itself output file to let the developer aware of the threat.
Continue reading...
ISCONNECT(). END. QUIT. server.p: DEF INPUT PARAM customerNumber AS INTEGER. DEF OUTPUT PARAM customerName AS CHAR. DO TRANSACTION: RUN srvMemLeak.p PERSISTENT. END. FIND FIRST customer WHERE custNum = customerNumber NO-LOCK NO-ERROR. IF AVAILABLE customer THEN customerName = Name. ELSE customerName = "No record". ASSIGN customerName = "This is just another test...". PAUSE 10 NO-MESSAGE. srvMemLeak.p USING Progress.Json.ObjectModel.*. DEFINE VARIABLE hq AS HANDLE NO-UNDO EXTENT 1000. DEFINE VARIABLE lp AS MEMPTR NO-UNDO EXTENT 1000. DEFINE VARIABLE jo AS JsonObject NO-UNDO EXTENT 1000. DEFINE VARIABLE i AS INTEGER. DO i = 1 TO 100: CREATE QUERY hq. set-size(lp) = 50000. jo = NEW JsonObject(). END. So, here, it would have been great if during the compilation of the source code above the ABL compiler had alerted me about a potential source of memory leaks relsted to the srvMemLeak.p where many objects were instantiated but never been deleted. So, here for example, in PDSOE, you can see that I compiled the source code: (*right click the picture below and select to open in a new tab or browser so that the picture will get bigger) And here in the problems tab I got no warning at all: Sometimes, some ABL object definitions are done inside include files what will spread to many other programs increasing the severity of the problem. So, the idea was to have at least an warn message in the problems tab or in the ABL compiler itself output file to let the developer aware of the threat.Continue reading...