CArray的内存泄漏

Question

In example I'm working on I have following situation, a parent – children relationship configuration up to 4 levels deep stored in database. Each item has 'id' and 'name' attribute. Because my English isn't so good a picture may be of help:

So basically, each parent can have number of children (except 4th level parent, it has no children, depth of 4 is limited). I need an object to store that 'tree' in memory. I decided to go with struct and array of them.

struct TEST_EXT_REASON
{
    int id;
    CString name;
    CArray<TEST_EXT_REASON*, TEST_EXT_REASON*> m_arrChildren;
    TEST_EXT_REASON::TEST_EXT_REASON()
    {
        id=0;
        name="";
    }
};

CArray<TEST_EXT_REASON*, TEST_EXT_REASON*> m_arrTestExtReason;

I'm having memory leaks issues when application closes.

This is my code snippets for populating the structure:

    void FillTestLevels(CMyView* pObject, TEST_EXT_REASON* pParent, int level, CString query)
{
    int err = mysql_query( myData1, query.GetBuffer(0), NULL );
    if(err) {
        AfxMessageBox(mysql_error(myData1)) ;
        return;
    }
    MYSQL_RES   * result;
    MYSQL_ROW   cur;
    result = mysql_store_result( myData1 ) ;
    if (!result) return;

    int cnt = mysql_num_rows(result);
    if(cnt==0) return;

    int id;
    char* desc;
    while ((cur = mysql_fetch_row(result)))
    {
        if (cur[0]) id=atoi((char *)cur[0]);
        else        id=0;
        if (cur[1]) desc = (char *)cur[1];
        else        desc = "";

        TEST_EXT_REASON* pLevel = new TEST_EXT_REASON;
        pLevel->id = id;
        pLevel->name = desc;
        if(!pParent && level==1) pObject->m_arrTestExtReason.Add(pLevel);
        else pParent->m_arrChildren.Add(pLevel);
    }
    mysql_free_result(result);

    if(level==4) return;

    if(!pParent && level==1)    
    {
        for (int i=0; i<=pObject->m_arrTestExtReason.GetUpperBound(); i++) 
        {
            TEST_EXT_REASON* pLevel = pObject->m_arrTestExtReason.GetAt(i);
            CString q_str;
            q_str.Format("SELECT id,name FROM reason_ext_lev WHERE id_parent = %d ORDER BY name", pLevel->id);
            FillTestLevels(pObject, pLevel, level+1, q_str);
        }
    }
    else
    {
        for (int i=0; i<=pParent->m_arrChildren.GetUpperBound(); i++) 
        {
            TEST_EXT_REASON* pLevel = pParent->m_arrChildren.GetAt(i);
            CString q_str;
            q_str.Format("SELECT id,name FROM reason_ext_lev WHERE id_parent = %d ORDER BY name", pLevel->id);
            FillTestLevels(pObject, pLevel, level+1, q_str);
        }
    }
}

Only in this function is where 'new' operator is used.

First time I'm calling this function is from 'MyView' with params 'pParent' NULL and 'level' 1, after that it's recursion at work (populating it self to the end).

pObject->DeleteTestExtReasonArrays();
str.Format("SELECT id,name FROM reason_ext_lev WHERE id_cfg = %d AND id_parent = 0 ORDER BY name", pObject-m_nConfigId);
FillTestLevels(pObject, NULL, 1, str);

This is how I'm releasing memory (in DeleteTestExtReasonArrays()):

void CMyView::DeleteTestExtReasonArrays()
{
    int size = m_arrTestExtReason.GetSize();
    for (int i=size-1; i>=0; i--)
    {
        TEST_EXT_REASON* pTmp = m_arrTestExtReason.GetAt(i);
        if(pTmp->m_arrChildren.GetSize()>0)
            DeleteTestExtReasonChildren(pTmp);
        m_arrTestExtReason.RemoveAt(i,1);
        delete pTmp;
        pTmp = NULL;
    }
    m_arrTestExtReason.RemoveAll();//I don't need this realy
}

void CMyView::DeleteTestExtReasonChildren(TEST_EXT_REASON* pParent)
{
    int size = pParent->m_arrChildren.GetSize();
    for (int i=size-1; i>=0; i--)
    {
        TEST_EXT_REASON* pTmp = pParent->m_arrChildren.GetAt(i);
        if(pTmp->m_arrChildren.GetSize()>0)
            DeleteTestExtReasonChildren(pTmp);
        pParent->m_arrChildren.RemoveAt(i,1);
        delete pTmp;
        pTmp=NULL;
    }
    pParent->m_arrChildren.RemoveAll();
}

The only problem is that I'm getting memory leaks and I cant find where. Every item is populated and at the end released. I'm working in VS6 (yes I know it's outdated but it's special case).

Answer 1

The parent/child stuff looks ok for me, though I would prefer to put the complete destruction stuff into TEST_EX_REASON's destructor. In my opinion, that's safer and more clearly.

I see a leak when a result doesn't contain rows. In this case, you return without calling mysql_free_result(result) previously.