Memory leak in Delphi XE8 and 10 Seattle

Discussion of open issues, suggestions and bugs regarding usage of dbExpress drivers for PostgreSQL in Delphi and C++Builder
Post Reply
ConwyValleySystems
Posts: 3
Joined: Tue 10 Nov 2015 06:56

Memory leak in Delphi XE8 and 10 Seattle

Post by ConwyValleySystems » Tue 10 Nov 2015 07:20

We have come across a problem in the recent versions of Delphi, XE8 and 10 Seattle, that there is a memory leak reported when we exit our application. We have raised this with Embarcadero, but I am posting here also in case anyone can help, or at least say that they have had the same problem also?

The leak can be reproduced with a very simple two line program:

SQLQuery1.SQL.Add('SELECT columns.table_name, columns.column_name FROM information_schema.columns'
+ ' WHERE columns.table_schema = ''public'' ORDER BY columns.table_name, columns.column_name;');
SQLQuery1.Active := true;

Adding this simple block of code to a FormCreate, for a form with TSQLQuery and TSQLConnection objects with properties set up so that a connection to a database is successful, gives a memory leak (as reported by EurekaLog). Here is an excerpt from the call stack:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|Methods |Details|Stack |Address |Module |Offset |Unit |Class |Procedure/Method |Line |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|+Leak #1: Type=Data at $0700AE40; Total size=512; Count=1 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|00000002|04 |00000000|0083CA20|Project4.exe|0043CA20|Data.DBXDynalink |TDBXDynalinkDriverCommonLoader|LoadDriverLibraryAndMethodTable |873[24] |
|00000002|04 |00000000|0083C6CF|Project4.exe|0043C6CF|Data.DBXDynalink |TDBXDynalinkDriver |LoadDriver |769[5] |
|00000002|04 |00000000|0083F46C|Project4.exe|0043F46C|Data.DBXDynalinkNative |TDBXDynalinkDriverNative |CreateConnection |87[1] |
|00000002|04 |00000000|0078D8EB|Project4.exe|0038D8EB|Data.DBXCommon |TDBXConnectionFactory |GetConnection |6661[12] |
|00000002|04 |00000000|0078D801|Project4.exe|0038D801|Data.DBXCommon |TDBXConnectionFactory |GetConnection |6640[0] |
|00000002|04 |00000000|007183E5|Project4.exe|003183E5|Data.DB |TCustomConnection |SetConnected |3567[8] |
|00000002|04 |00000000|00829241|Project4.exe|00429241|Data.SqlExpr |TCustomSQLDataSet |OpenCursor |4066[2] |
|00000002|04 |00000000|0072BC91|Project4.exe|0032BC91|Data.DB |TDataSet |SetActive |12470[12] |
|00000002|04 |00000000|00868C68|Project4.exe|00468C68|Unit6 |TForm6 |FormCreate |35[6] |
|00000002|04 |00000000|006C6295|Project4.exe|002C6295|Vcl.Forms |TCustomForm |DoCreate |3758[3] |
|00000002|04 |00000000|006C5EB5|Project4.exe|002C5EB5|Vcl.Forms |TCustomForm |AfterConstruction |3642[1] |
|00000002|04 |00000000|006C5E65|Project4.exe|002C5E65|Vcl.Forms |TCustomForm |Create |3632[35] |
|00000002|04 |00000000|006D0DEA|Project4.exe|002D0DEA|Vcl.Forms |TApplication |CreateForm |10557[13] |
|00000002|04 |00000000|008755D5|Project4.exe|004755D5|Project4 | |Initialization |23[3] |
|00000002|03 |00000000|76F17BFC|kernel32.dll|00017BFC|KERNEL32 | |BaseThreadInitThunk | |
|00000002|03 |00000000|7769AD1D|ntdll.dll |0005AD1D|ntdll | | (possible RtlInitializeExceptionChain+141)| |
|00000002|03 |00000000|7769ACE5|ntdll.dll |0005ACE5|ntdll | | (possible RtlInitializeExceptionChain+85) | |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|


We are not suggesting that the Devart DBExpress PostgreSQL driver is leaking memory - it appears that we have simply uncovered a memory leak in Embarcadero's source code used in XE8 and 10 Seattle. Running the same exact code in XE7 does not give the leak (and we have tried using the last few versions of the Devart DBExpress PostgreSQL driver i.e. all combinations of driver version and Delphi version, and regardless of what driver version we use, the leak only occurs in XE8 and 10 Seattle, and never in XE7).

If anyone can shed any insight into this issue it would be much appreciated!

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Re: Memory leak in Delphi XE8 and 10 Seattle

Post by AlexP » Thu 12 Nov 2015 11:16

Hello,

Thank you for the information, we have reproduced and fixed the issue. This fix will be included in the next version.

ConwyValleySystems
Posts: 3
Joined: Tue 10 Nov 2015 06:56

Re: Memory leak in Delphi XE8 and 10 Seattle

Post by ConwyValleySystems » Thu 12 Nov 2015 12:05

Thanks for looking into this! Can I ask when the next version of the drivers, containing this fix, will be released? We cannot deploy our application built under 10 Seattle until this is resolved.

Many thanks!

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Re: Memory leak in Delphi XE8 and 10 Seattle

Post by AlexP » Thu 12 Nov 2015 13:10

We can send you a night build. For this, please send your license number to alexp*devart*com.

ConwyValleySystems
Posts: 3
Joined: Tue 10 Nov 2015 06:56

Re: Memory leak in Delphi XE8 and 10 Seattle

Post by ConwyValleySystems » Mon 07 Dec 2015 15:21

Alex - I haven't heard back from you since my last couple of emails to you on this matter. If you want me to re-send or post the details here, that's fine, but we really do need a full solution to this. Thanks!

azyk
Devart Team
Posts: 1072
Joined: Fri 11 Apr 2014 11:47
Location: Alpha Centauri A

Re: Memory leak in Delphi XE8 and 10 Seattle

Post by azyk » Thu 10 Dec 2015 09:57

We have investigated your sample. Our dbExpress driver for PostgreSQL doesn't cause memory leak. The issue with memory leak is also reproduced with the standard dbExpress drivers for the other databases (Firebird, MSSQL, MySQL) starting from RAD Studio XE8 and higher.

To resolve the issue, please contact RAD Studio developers.

Post Reply