VB6 Memory Leaks Without GDI Leaks

All the advice I've found on debugging memory leaks in VB6 code has focused on GDI leaks. In my situation, however, evidence suggests that I don't have a GDI leak but probably do have a memory leak. What might be some likely candidates for the cause of such a leak, and/or go开发者_开发技巧od tools to help me determine the portion of my program which is causing this?

---

Unfortunately VB6 does not have enough debugging instrumentation to detect object leaks. I'm usually implementing instance book-keeping on my own in every class, form or user control with a couple of helper functions. The basic pattern is like this

Private Const MODULE_NAME As String = "<<class_name_here>>"

#If DebugMode Then
    Private m_sDebugID          As String
#End If

#If DebugMode Then
    Private Sub Class_Initialize()
        DebugInstanceInit MODULE_NAME, m_sDebugID, Me
    End Sub
#End If

#If DebugMode Then
    Private Sub Class_Terminate()
        DebugInstanceTerm MODULE_NAME, m_sDebugID
    End Sub
#End If

Helper function DebugInstanceInit generates next sequential id and assigns it to m_sDebugID, then stores module name and ObjPtr(Me) in a collection, keyed on the id.

Helper function DebugInstanceTerm removes entry from the collection using m_sDebugID as a key.

This way in every moment of application execution you can dump this instance collection and identify count and type of objects that are allocated but still not terminated. If continuous opening and closing of forms increments object count you are leaking objects probably due to circular references (e.g. collection->entries and entry->collection).

Most frameworks and other languages have this kind of book-keeping built-in (at least in debug builds) but unfortunately VB6 has poor support for source code metadata (MODULE_NAME, FUNC_NAME, LINE_NUMBER) and object lifetime management. Lack of implementation inheritance hurts here too.

---

Generically, you have to watch for circular references. In VB6, an object will remain in memory as long as it is referenced somewhere. So if you have an object-type variable as a member of a form (for example) then it will be in memory until that form is Terminated (unless you explicilty set it to nother early of course). And that reference chain can be very deep:

Here, FormA is keeping ObjectB and ObjectC in memory:

FormA -> ObjectB -> ObjectC

What you need to watch for is something like this:

FormA -> ObjectB <-> ObjectC

ObjectB has a reference to ObjectC and ObjectC has a back or parent reference to ObjectB. Even if FormA is Terminated or otherwise clears it reference to ObjectB, ObjectB and ObjectC will live forever and represent a memory leak.

---

good tool for finding memory leaks is deleaker. you can try it. And check yet one thing - are there still GDI leak or not. You must be sure!