Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Memory leak: EasyDAClient stays live after Dispose() and set it to null.

More
27 Feb 2015 10:56 #2863 by support
Great. Oh yes, in the end I am grateful that you have pointed out the issue, it helps the product in the long run to have these fixed!

BTW, you should really switch to version 5.32+ for your next release/version, as it becomes increasingly difficult to support version 5.23, and there are already bug fixes that do *not* go into that version. This particular problem was present in both old and new versions, but you get the point... There will be no guaranteed support for version 5.23 after January 31, 2016 (even if somebody purchases the maintenance contract now, it will not include that support).

Thank you once again!

Best regards

Please Log in or Create an account to join the conversation.

More
27 Feb 2015 08:08 #2862 by Emilio
I downloaded the new version 5.23.2093.1 and tested everything again with huge OPC traffic.
Everything is perfectly fine now!

I thank you very much for the (very) quick reaction, I also think that this way of cooperating together really works.

Best regards,
Emilio

Please Log in or Create an account to join the conversation.

More
26 Feb 2015 14:08 #2857 by support
Please download QuickOPC 5.23 build 2093.1 from our public Web site.

I have used a different analysis tool (fotMemory from JetBrains), but I saw about the same symptoms. After the fix, I can still see some remaining objects when the code finishes, but they are statically rooted instances that are perfectly fine (do not grow with usage), such as license info etc.

Yes, OPC Labs is sponsoring the OPC Europe Day in Paris, and I will be there.

Best regards
Zbynek Zahradnik

Please Log in or Create an account to join the conversation.

More
25 Feb 2015 15:27 #2854 by Emilio
Hello Zbynek,

this is a gerat piece of news!

I've done some experiment in order to provide as many details as possible, I'd rather prefer to wait for a clean solution obviously.

I think we'll meet in Paris, OPC Europe Days, are you there?

Thanks,
Best regards,
Emilio

Please Log in or Create an account to join the conversation.

More
25 Feb 2015 11:48 #2853 by support
Emilio,

I think I have found the problem, and I am working on a fix. I will let you know.
Best regards

Please Log in or Create an account to join the conversation.

More
25 Feb 2015 10:24 #2852 by Emilio
Some more details:

Even if I do not create and Dispose() an instance of EasyDAClient, just keep one instance, the memory leak seems to be related to the subscriptions.

Example:
I have 1000 items under subscriptions. One instance only of EasyDAClient.
Subscribe and unsubscribe them 10 times.

At the end, observed with RED GATE ANTS Memory Profiler:
Unmanaged code +8M
Managed code (mainly the state objects) +1.4M

I can reduce the state objects, I couls even remove them, we would have a slightly worse performance, but I cannot deal with unmanaged code.

Hopefuly it helps a bit...

Thanks,
Best regards,
Emilio
The following user(s) said Thank You: support

Please Log in or Create an account to join the conversation.

More
24 Feb 2015 14:32 #2850 by Emilio
I have some other result concerning this issue.
Maybe it helps.

The state object that is associated to each subscription is not released after Unsubscribe() and Dispose(). The sample code from this post (at the beginning) is the same. This is what makes the biggest memory leak, because in the real application the state object is a List<some_other_object>.

I've just tried now to implement a second example where the state object is an int (32-bit int) and I observed that the int, somehow wrapped into an object (the size is exactly 24 bytes), remains alive in the heap.

I can use integer as state objects also in the real application, keeping all other objects only locally at my side, then I lose 24 bytes each time a subscription is terminated.

I've just calculated that in the real world, with real numbers, we might reach soon some megabyte memory leak, not hundreths mega as we reached last week when we still had object references as state.

I have to decide now whether to change implementation or keep it as it is, based on your feedback about this issue.

Once again, thanks a lot for support,
best regards,
Emilio

Please Log in or Create an account to join the conversation.

More
23 Feb 2015 06:10 #2838 by support
Thank you. I will investigate this.

Best regards

Please Log in or Create an account to join the conversation.

More
20 Feb 2015 14:14 #2828 by Emilio
I write here the complete version of one component, it should suffice:

OpcLabs.EasyOpcClassic.dll
OPC Labs EasyOPC.NET Library
File version: 5.23.1142.1

Please Log in or Create an account to join the conversation.

More
20 Feb 2015 13:57 #2826 by support
Emilio,

please remind me which version and build of QuickOPC is this observed with.

Best regards

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.076 seconds