Memory Leak with Oracle Timestamp

[Volker.Maier]

Hello,

we encountered a memory leak using unidac, details as following:

UniDac 6.3.12 for RAD Studio 2010
Oracle 12, Client 12.1.0
Connection via TNS

Steps to reproduce:

1.Launch standard demo program which ships with unidac (UniDacDemo.dpr)
2. connect to oracle db via TNS
3. Go to the Query-tab
4. execute a select against a table which contains the data type oracle timestamp
CREATE TABLE ...."MyField" TIMESTAMP (6) DEFAULT SYSTIMESTAMP NOT NULL ENABLE

5. if the amount of rows returned equals or exceeds the RowFetch-property which can be adjusted in the application too, a memory leak will occur

To verify this, execute the query often enough and watch the taskmanager. I added a loop to execute 1000 times which gives a pretty clear result

eurekalog was not able to find anything here, but its obvious that memory is lost.

This is an urgent matter for us, we are using the site license for years an need some fix/information really soon.

Thank you very much,
Volker Maier

[MaximG]

We have checked functionality of UniDAC 6.3.12 when using fields of the TIMESTAMP type in Oracle database. Unfortunately, we couldn't detect a memory leak on multiple open/close operations of the UniQuery component. Obviously, an application will consume a volume of memory on opening a dataset, that is demonstrated by Windows Task Manager. However, memory leak may be detected only using a memory manager: FastMM4, EurecaLog, madExcept and etc. For further investigation, please compose a small sample, in which you can detect a memory leak using one of the above memory managers, and send it to us.

[Volker.Maier]

Thank you for your reply.

I am well aware that the memory consumption is not stable and will vary wether data is being loaded etc.

But in this case the memory usage will let the application increase in size from starting 30mb to 100, 500, 1gb and more. And its definitely connected to the ROWFETCH-Property. As long as the amount of resultrows are lower, there is no problem, no matter how often the query is executed.

So i went through it, added the UniDac-Sources to your test-project and activated eurekalog again.

Parameter FetchRows = 25
SQL : "select wtas_date_upd from tblwms_tasks where rownum < 26"
(note that as i said before, amount of rows must equal or be greater than FetchRows)

I once again used your own application, this time without modification for a loop etc.
no parameters, options etc. where changed.

the result is as follows :

EurekaLog 7.3.2.0

Exception:
------------------------------------------------------------------------
2.2 Address: 00A6E837
2.5 Type : EMemoryLeak
2.6 Message: Application has leaked memory: Total size=1206; Count=25.
2.7 ID : 6A2F0001
2.11 Sent : 0

Leaks Information:
------------------------------------------------------------------------------------------------------------------------------------------
|Methods |Details|Stack |Address |Module |Offset |Unit |Class |Procedure/Method |Line |
------------------------------------------------------------------------------------------------------------------------------------------
|+Leak #1: Type=TOraTimeStamp; Total size=1206; Count=25 |
|----------------------------------------------------------------------------------------------------------------------------------------|
|00000002|04 |00000000|00A6E837|UniDacDemo.exe|0066E837|OraClassesUni|TOCIRecordSet |InitBlock |14410[41] |
|00000002|04 |00000000|00A6EE10|UniDacDemo.exe|0066EE10|OraClassesUni|TOCIRecordSet |FetchArray |14577[95] |
|00000002|04 |00000000|00A6D44C|UniDacDemo.exe|0066D44C|OraClassesUni|TOCIRecordSet |InternalFetch |13935[4] |
|00000002|03 |00000000|006FCFF6|UniDacDemo.exe|002FCFF6|CRAccess |TCRRecordSet |Fetch | |
|00000002|04 |00000000|00A70802|UniDacDemo.exe|00670802|OraClassesUni|TOCIRecordSet |DoFetchAll |15218[15] |
|00000002|04 |00000000|00A70A91|UniDacDemo.exe|00670A91|OraClassesUni|TOCIRecordSet |FetchAll |15291[18] |
|00000002|04 |00000000|00A6801C|UniDacDemo.exe|0066801C|OraClassesUni|TOCIRecordSet |EndExecFetch |12196[18] |
|00000002|04 |00000000|00A683E3|UniDacDemo.exe|006683E3|OraClassesUni|TOCIRecordSet |ExecFetch |12287[40] |
|00000002|03 |00000000|006FA46C|UniDacDemo.exe|002FA46C|CRAccess |TCRRecordSet |InternalOpen | |
|00000002|04 |00000000|00A67A07|UniDacDemo.exe|00667A07|OraClassesUni|TOCIRecordSet |InternalOpen |12029[3] |
|00000002|03 |00000000|00648350|UniDacDemo.exe|00248350|MemData |TData |Open | |
|00000002|03 |00000000|006D8BB0|UniDacDemo.exe|002D8BB0|MemDS |TMemDataSet |InternalOpen | |
|00000002|03 |00000000|006D1F1D|UniDacDemo.exe|002D1F1D|DB |TDataSet |DoInternalOpen | |
|00000002|03 |00000000|0077AB3F|UniDacDemo.exe|0037AB3F|Uni |TCustomUniDataSet|OpenCursor | |
|00000002|03 |00000000|006D1E91|UniDacDemo.exe|002D1E91|DB |TDataSet |SetActive | |
|00000002|04 |00000000|00725A5D|UniDacDemo.exe|00325A5D|DBAccess |TCustomDADataSet |SetActive |7936[4] |
|00000002|03 |00000000|006D1CD8|UniDacDemo.exe|002D1CD8|DB |TDataSet |Open | |
|00000002|03 |00000000|005FE4DF|UniDacDemo.exe|001FE4DF|Controls |TControl |Click | |
|00000002|03 |00000000|005FE917|UniDacDemo.exe|001FE917|Controls |TControl |DoMouseUp | |
|00000002|03 |00000000|005FDB98|UniDacDemo.exe|001FDB98|Controls |TControl |Perform | |
|00000002|03 |00000000|00602168|UniDacDemo.exe|00202168|Controls |TWinControl |IsControlMouseMsg | |
|00000002|03 |00000000|00601EDC|UniDacDemo.exe|00201EDC|Controls |TWinControl |MainWndProc | |
|00000002|03 |00000000|00472284|UniDacDemo.exe|00072284|Classes | |StdWndProc | |
|00000002|03 |00000000|768762F7|user32.dll |000162F7|USER32 | | (possible gapfnScSendMessage+815)| |
|00000002|03 |00000000|76876D35|user32.dll |00016D35|USER32 | | (possible GetThreadDesktop+210) | |
|00000002|03 |00000000|768777BF|user32.dll |000177BF|USER32 | | (possible CharPrevW+307) | |
|00000002|03 |00000000|76877883|user32.dll |00017883|USER32 | |DispatchMessageW | |
|00000002|03 |00000000|005D6088|UniDacDemo.exe|001D6088|Forms |TApplication |ProcessMessage | |
------------------------------------------------------------------------------------------------------------------------------------------

[andrefm]

For some reason I also have memory leak as posted at:
viewtopic.php?f=28&t=33299

I had a long annual leave and will try again as I also have constant issues with memory consumption.
Maybe the problem was related to my previous DEV environment and therefore I will install now Delphi Berlin and only UNIDAC and make the same tests from my post.

[andrefm]

Thx Volker for the tip.
For me this is a bug, but the memory leak in my application disappeared after I changed the amount of rows to fetch from 25 to 1000 (which I will not get more than that in my case). This way at least I don't see memory leak errors anymore (FASMM). Better this workaround for the mean time as I was even thinking of changing to FireDAC as this was causing some headaches for a program which runs 24/7.

[MaximG]

Unfortunately, we couldn't detect a memory leak in UniDAC when using EurekaLog 7. For further investigation, please send us a sample project reproducing memory leak working with the OracleUniProvider to maximg*devart*com .

[MaximG]

We have already fixed memory leak in UniDAC when using Oracle TimeStamp datatype. We plan to release the build in 2 week.

[Volker.Maier]

thats great, thank you!

Out of curiosity and out of my own analysis:
The problem was, that the FFetchBuffer is being allocated once and then free'd after the fetch. Once the buffer is full its being overwritten by the new data. but since the ora time stamp is an object, just the pointer is being overwritten, but the object not free'd, except for the last fetch.

Thats correct?

[MaximG]

Yes, you are right. The issue was due to this exactly. We have already fixed this bug. The fix will be included in the next UniDAC build.

[Volker.Maier]

Thank you for the confirmation.

Its more than 1 week later than you planned your release. Is this release going to be out in the next days or will there be a considerable delay?

We have high performance processes at customers with high availablitiy and we are suffering severely under the leak forcing us to restart processing regularly.

Can you please confirm the release date? Or if its not possible due to other issues could you provide the bugfix for this leak?

Thank you in advance,
Volker Maier

[MaximG]

We plan to release the build this week. Currently, we can send you a night build of UniDAC with the fix. For this, please specify your license number to maximg*devart*com