Next, I tested the same project with QuickOPC 5.31.1331.1. Here are the results:



(with approx. 81,200 loop cycles).
There are no signs of memory leak (the thick green line).

My conclusion is that the leak is fixed in Version 5.31. I can kind of guess what has happened - the problem might have been in the area of various EasyDAClient parameter objects, which were originally implemented in C++/CLI, but have been significantly rewritten (with parts moved to C#) in version 5.31.

I do not plan to fix this in versions 5.23 or 5.30 (if it's there).

Results of my test with QuickOPC 5.23.1196.1, only EasyDAClient instantiations (project attached):



Some observations:

• Approx. 149,700 loop cycles throughout 24 hours
• Increase in "Private Bytes" (thick red line) very roughly 10 MB
• GC being called by the CLR, no need to invoke explicitly
• The lower level of "# Bytes in all Heaps" increased by approx. 3 KB (!, from approx. 507,000 to 510,000), the upper level as well
• Counters like "Handle Count", "Thread Count", "# of Pinned Objects", "Finalization Survivors" show no proof of leak

From: B.
Sent: Wednesday, September 03, 2014 8:14 AM
To: Zbynek Zahradnik
Subject: FW: [our app] memory leak test 2

Zbynek,

Here is the answer from S.

Regards
B.

From: S.
Sent: den 3 september 2014 08:05
To: B.
Subject: SV: [our app] memory leak test 2

Yes I confirm. I have not tested exactly that particular scenario. But I’m pretty sure you should get a memory leak from it.

/S.

Från: B.
Skickat: den 2 september 2014 19:18
Till: S.
Kopia: Zbynek Zahradnik
Ämne: FW: [our app] memory leak test 2

S.,

Can you please answer me the question from ZZ.

/B.

From: Zbynek Zahradnik
Sent: Tuesday, September 02, 2014 5:18 PM
To: ...
Subject: RE: [our app] memory leak test 2

Can you please confirm that the minimum scenario to get the supposed leak would be with the code you sent, but with the following lines commented out:?

Write(); // Write counter to file

DAVtq vtq = client.ReadItem(server, item);
Console.WriteLine("{0} {1} {2}", vtq.Timestamp.ToString("yyyy:mm:dd HH:MM:ss.fff"), vtq.Value, vtq.Quality.QualityChoiceBitField);

From: B.
Sent: Tuesday, September 02, 2014 4:01 PM
To: Zbynek Zahradnik
Subject: FW: [our app] memory leak test 2

Zbynek,

Here is codesample and little more information around the memorychanges.

*********************************************************
Hi ZZ!

I have made a new small application calling the EasyDACLient.ReadItem() to your KitServer reading only Demo.Ramp as fast as possible(500ms Sleep).
This application I had running for about 4½ days and it clearly builds memory. Please see attached source code so you can run it for yourself. This application also suffers with the problem that the Dispose method takes long time to execute. I have not had time to test your work-around. I will do that next thing and also see if I can implement that in [our app].
The application used QuickOPC V5.23.1052.1. Here is a table of how the memory is growing:

Time Private bytes (kB) Peak private bytes (kB)
2014-08-28
16:19 (start) 28220 - 28408 28536
16:30 28224 - 28416 28640
2014-08-29
08:08 29380 - 29556 29756
12:01 29664 - 29784 29976
15:30 29900 - 30132 30196
2014-09-01 (after weekend)
08:23 33248 - 33428 33564
13:04 33444 - 33632 33756
16:25 33648 - 33824 33956
2014-09-02
08:02 34416 - 34592 34724
09:22 34480 - 34664 34792

After 2014-09-02 09:22 I shut off the test. It clearly builds memory.



One more things. I have also tested [our app] with these specifications:
• Without any reference to QuickOPC what so ever.
• Only instantiating the EasyDAClient, calling Dispose() and had automatic subscribtions OFF. There was no calling to any of the Read methods in EasyDAClient.

The results are:
• Without QuickOPC in [our app] the memory stabilized after one day.
• With QuickOPC the memory kept growing.

My conclusion is that there is a memory leak in QuickOPC by just instantiating the EasyDAClient several times as we do in [our app].
I have logged the values of the memory of both tests if required.

/S.

**************************************************************

Best regards
B.