reference leaks

[aartjan]

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

[Mikael-ANSCENTER]

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.

[aartjan]

The utility VI GetClassAttributes.vi has this block diagram:

[MikaelH · Accepted solution]

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:

[aartjan]

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.

[MikaelH]

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.