09-11-2022 06:31 AM
I seem to have reference leaks in some of my DVR GOOP classes. I don't believe these classes are singleton like described in this thread, because I can set class attributes. I found the reference leaks with the Desktop Execution Trace Toolkit (DETT). My application crashes on a production server upon closing the application, even though it never crashes on any of my devand test machines. The reference leak errors appear in DETT when I close the executable.
One in particular that is part of GOOP is classname.GetClassAttributes.vi. This is one of the utility VIs that uses a queue that isn't de-allocated when an object is terminated. How can I deallocate this class reference? Isn't it supposed to be de-allocated automatically when all objects are terminated?
I use OpenGOOP version 1.2.72 (135) 32bit in LV2020.
Aart-Jan
Solved! Go to Solution.
09-11-2022 04:41 PM
Hi,
Can you send me some example code I can have a look?
For a Non-Singleton class (that is not named) the only reference that is created is the DVR inside the <ClassName>_New.vi
And this reference is/should be released in the Destroy.
The Destroy VI could look sometime like this:
But if you name the object (only needed in special circumstances), then that 1 element queue that keeps the reference in memory is not released automatically, then you have to add a release queue in the end of your destroy manually.
09-12-2022 03:59 AM
The utility VI GetClassAttributes.vi has this block diagram:
09-12-2022 04:19 PM
You are right, that design pattern "ClassAttribute" don't give you a way of destroying that Named Queue.
But you could always wire the name out of the queue to an indicator so you can force destroy it like the above example.
I have updated this VI in the latest version of the tool (I'm currently running 1.2.85, you'll find it under beta testing).
That version looks like this:
But since this VI is not re-entrant (and if we keep it that way, we could just change the code to this:
But still you have to make the decision of when it's okay to release this ClassAttribute DVR reference.
Something like this:
09-15-2022 04:04 PM
Thanks Mikael, that will work for me.
I ended up not calling the class methods at all in my project. Was a quick and dirty solution.
09-15-2022 04:20 PM
Class attributes/Variables should only be used in rare cases.
Class attribute could also just be implemented with a private Global variable in the class, but those can cause race conditions, so a FGV/ActionEngine might be enough.