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.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Reading, Writing, Subscriptions, Property Access
- Memory leak: EasyDAClient stays live after Dispose() and set it to null.
Memory leak: EasyDAClient stays live after Dispose() and set it to null.
27 Feb 2015 10:56 #2863
by support
Replied by support on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
27 Feb 2015 08:08 #2862
by Emilio
Replied by Emilio on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
26 Feb 2015 14:08 #2857
by support
Replied by support on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
25 Feb 2015 15:27 #2854
by Emilio
Replied by Emilio on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
25 Feb 2015 11:48 #2853
by support
Replied by support on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
Emilio,
I think I have found the problem, and I am working on a fix. I will let you know.
Best regards
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.
25 Feb 2015 10:24 #2852
by Emilio
Replied by Emilio on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
24 Feb 2015 14:32 #2850
by Emilio
Replied by Emilio on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
23 Feb 2015 06:10 #2838
by support
Replied by support on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
Thank you. I will investigate this.
Best regards
Best regards
Please Log in or Create an account to join the conversation.
20 Feb 2015 14:14 #2828
by Emilio
Replied by Emilio on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
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
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.
20 Feb 2015 13:57 #2826
by support
Replied by support on topic Memory leak: EasyDAClient stays live after Dispose() and set it to null.
Emilio,
please remind me which version and build of QuickOPC is this observed with.
Best regards
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
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Reading, Writing, Subscriptions, Property Access
- Memory leak: EasyDAClient stays live after Dispose() and set it to null.
Time to create page: 0.063 seconds