Note that if the method is an instance method of a class, the returned delegate will also retain a reference to the class object. This can, in some cases, lead to circular references, causing memory leaks if they’re not explicitly broken up after use. To avoid this complication, consider using WeakAddressOf, which will reference the class object via a WeakRef, thereby avoiding the side effects of circular referencing.
So maybe I am having reading comprehension issues today, but why wouldn’t the problem with the leak be with the app class going away. The class being referenced is App right?
So if the page his button is on goes away, what difference does it make that the reference is weak or not. It’s not the app class reference that is being collected it’s the button class instance.
Am I missing something obvious or am I just being dense today?
I believe you can get the number of objects allocated by the runtime through a function call. The memory is just stacking up outside of your control.
A change you could make is to check if the socket already exists and remove all handlers before creating the new instance. That should eliminate the memory leak
Hi Kevin - the “email engine” I’m creating will live at the App level, and persist 24/7 as a WebService. There won’t be any Sessions - the services of this app will be published (API) and consumed by other apps. Hope that helps clarify.
Like most of my work I like to force it to break, so I know the limitations and when to put certain safeguards in place. The fact that I couldn’t get a malfunction of my SMTPSecureSocket structure is what lead me to create this post. It seems it’s rightfully lead me into a deep dive!
I’m totally going to create some Runtime readings in my “backend” UI and monitor this, and see if I can help concretely answer the pointer/leak questions. Writing this into my testing right now…
Yo have a very basic missconception about objects. A variable is a reference, NOT the class nor the object itself. The class referenced is an instance of SMTPSecureSocket
Yeah I was thinking based on the AddHandler docs that the reference it was referring to was the class that has the method being used as the handler.
I guess I should make a little test app to figure this out in practice. I can’t recall ever having an issue using AddHandler, but maybe I have some bugs and didn’t know it or just got lucky.
In order to wor, the Handler must have BOTH references, one for the object and another for the delegate method.
This days a couple hundred objecs leaked in memory could be not noticeable. This only became a mayor problem when you have many more and/or with bigger memory usage.
It makes a lot more sense to me if there is another object involved that gets created when you use AddHandler. That had not occurred to me in the past, but it seems like that is the case. Again, I should probably test it myself to verify, but I probably shouldn’t even be reading the forums as I have too many other things I should be doing.
I’m running with @DerkJ suggestion and simply subclassing it. So far after a few minutes of dinking around I can see it’s going to be a better way. Thanks Derk!
