Fixing memory leak

[Don803]

I have inherited an app that has 25 classes in 6 dlls.

I have a memory leak that appears after several days.

I know that I have to set my objects to nothing.

My questions are. . .

How do I determine what to set to nothing?

adodb.connection
adodb.command
adodb.recordset
MSXML2.DOMDocument
what else. . .
----------------------------
How do I clean something like this up?

public function getLeaf() as LeafObject
dim myTree as new TreeObject
dim myBranch as object
set myBranch = myTree.GetBranch(0)
dim myTwig as object
set myTwig = myBranch.GetTwig(55)
dim myLeaf as LeafObject
set myLeaf = myTwig.GetLeaf(99)

return myLeaf
EndFunction

 

[NewGuy]

I am not an expert but from what I have read I think the answer is:

If you use the keyword "SET" to for a variable then make sure to do the Set <var> = Nothing.

 

[Don803]

OK, in my example, I pass the LeafObject myLeaf out of the function.
Is it safe to set myLeaf to nothing before exiting the function?
--------------------------
In the calling sub, let's say I have. . .

set gobjNewLeaf = getLeaf()

Since it is a global, where do I set it to nothing?
--------------------------
If I use it later in another sub, like. . .

intNewLeafColor = gobjNewLeaf.ColorNumber

Do I need to set it to nothing there?

Thanks for your feedback. I need to have a good plan in place before I set about trying to clean up all of this code.

 

[NewGuy]

Only use "Set <variable> = nothing" when you are all done with it.

The reason is that setting a variable to nothing completely wipes out the contents of the variable.

This is what I understand.

I hope it helps.

Maybe someone else wants to step in and add comments???

 

[BobRodes]

VB is supposed to clean up objects when it's done with them. There are circumstances when this doesn't happen, and also circumstancesw when the objects themselves are responsible for memory leaks. It's best practice to set object references to nothing in VB6 when you're done using them.

You can also implement a "just in time" logic, wherein you instantiate an object whenever you use it and then set it to nothing when you are done. A good example of this is disconnected recordsets, where you instantiate a connection object, open it, use it to open your recordset, close the connection, and set it to nothing. You'll have your recordset, and when you want to batch post updates, you can reinstantiate the connection object, reopen it, and reference it from your recordset.

If you're working with an existing application, it might be a good idea to put together a UML Class diagram to figure out what is working with what. To figure out how objects interact, you can also work with an object diagram.

If you go this way, handle global data by treating standard modules as classes of the utility type. (Use the <<utility>> stereotype.)

Feel free to ask questions if you need further help.

Bob

 

[Don803]

After looking at your posts, talking with an associate, and looking at the code base I am using, I have decided to do the following.
-------------------
local objects

If Not MyObject Is Nothing Then
MyObject.Shutdown
Set MyObject = Nothing
End If
-------------------
Global / module level objects

Public Sub Shutdown()

If Not mobjThis Is Nothing Then
mobjThis.Shutdown
Set mobjThis = Nothing
End If

If Not mobjThat Is Nothing Then
mobjThat.Shutdown
Set mobjThat = Nothing
End If

End Sub
-------------------
If I take this approach with all of my classes, I am hoping my memory leak goes away.

Tell me if I am missing anything.