View Incident Report

Serious

Reported By: Johan Dorrestijn
Reported On: 12/7/2012
For: Version 4.34 Build 6

# 3710 Creating In-Memory Tables Can Cause Minor Memory Leak Across Multiple Sessions

My DBISAM version is V4.31 build3 (I use it C/S). To be able to see the (remote) DBSRVR memory consumption I have recompiled the DBSRVR to show the actual memory status, see the source code below I found somewhere on the internet.

The function result works fine and I can see the DBSRVR memory status going up and down as expected (using RemoteSession.GetRemoteMemoryUsage).

But once I execute a query statement with "INTO MEMORY\TEMPTABLE" then after closing the application the final GetMemoryUsage result is always 96,6 kB higher than it was before. How many times I run the query in the client-application does not matter. I do execute a DROP MEMORY\TEMPTABLE after use. Calling RemoveRemoteMemoryTables has no effect on this.

If I execute the client application again and again memory consumption on the server keeps on growing. Even if I use DBSYS to test this situation it has the exact same result.

Only after restarting the DBSRVR the memory consumption it shows is back to 'normal' again. My clients using my application, working all day starting and ending the application experience the same thing and now and then the only 'workaround' is to restart the DBSRVR.

changes apply to sourcefile dbisamsv.pas:

function TDataServer.GetMemoryUsage: double;
var
  AMemoryManagerState: TMemoryManagerState;
  SBTState: TSmallBlockTypeState;
begin
  Result:=0;
  GetMemoryManagerState(AMemoryManagerState);
  with AMemoryManagerState do
     begin
     for SBTState in SmallBlockTypeStates do
        Result:=Result+SBTState.AllocatedBlockCount*SBTState.UseableBlockSize;
     Result:=Result+TotalAllocatedMediumBlockSize;
     Result:=Result+TotalAllocatedLargeBlockSize;
     end;
  Result:=Result/1024;  //Result in kB
end;

the simple test SQL I use is:

select MyField
into memory\temptable
from MyTable;

drop table memory\temptable;

Comments

The key item was the new process execution, and the cause of the memory consumption was the creation of a new in-memory lock file per process. The in-memory lock files are named per process, so they were being created for each process but never freed, and each would allocate a 64k block for the memory file.

Resolution

Fixed Problem on 1/11/2013 in version 4.34 build 7

Products Affected

DBISAM Additional Software and Utilities
DBISAM ODBC Client-Server
DBISAM ODBC Client-Server with Source
DBISAM ODBC Standard
DBISAM ODBC Standard with Source
DBISAM ODBC Trial
DBISAM VCL Client-Server
DBISAM VCL Client-Server with Source
DBISAM VCL Standard
DBISAM VCL Standard with Source
DBISAM VCL Trial

More Support Options

Search Incident Reports

Support Forums

Frequently Asked Questions

Technical Bulletins

Technical Articles

Product Manuals

Roadmap