Odd false positive, why? And how to handle properly?

Feb 23, 2011 at 12:01 PM
Edited Feb 23, 2011 at 3:41 PM

What is the right way to handle false positives? I have at least two reported leaks that
are plain wrong. It's funny because for example for the first false positive in the code there are
15 similar places where it could produce one but it picks just one of those, which looks odd.
I have no idea at all how it can even believe there would be a leak. it's quite simple code.

To show what i mean, i'll post it here:

switch(type)
{
case gui::EGWT_A:
parseA(current, theme, prefix);
break;
case gui::EGWT_B:
parseB(current, theme, prefix);
break;
case gui::EGWT_C:
parseC(current, theme, prefix); // here only ?
break;
case gui::EGWT_D:
parseD(current, theme, prefix);
break;
case gui::EGWT_E
//.......

 

now the code. as said, all the parse functions are all the same, just different types, but same logic and length.

void parseC()
{
        gui::SSomeStruct *stheme = new gui::SSomeStruct();
        core::CTree *current = root->getElement("name",false);
        if(current)
        {
            theme->somestructs[current->getValue()] = stheme;
        }
        else
        {
            log("No name found");
            delete stheme;
            return;
        }
}

to make it more clear what i mean, i'll give an example of how another parse function looks like in my code:

void parseB()
{
        gui::SSomeTotallyOtherStruct *stotheme = new gui::SSomeTotallyOtherStruct();
        core::CTree *current = root->getElement("name",false);
        if(current)
        {
            theme->sometotallyotherstructs[current->getValue()] = stotheme;
        }
        else
        {
            log("No name found");
            delete stotheme;
            return;
        }
}

it doesnt help to re-arrange this code, i tried to other re-arrangements, one with allocating
only when i need the struct. the other one was to delete and return without an else() but return
before when successful.

and of course, what is the proper way to handle this? embody this into a pair of
VLDDisable /Enable pair? i'm not so sure of that.

 

With regards,
cal

Developer
Feb 28, 2011 at 8:48 PM

Well, it seems to me that you can get a leak when current is a valid pointer. Then the stotheme pointer never gets deleted. 

Doesn't seem hard to me.

Feb 28, 2011 at 10:49 PM

It will get deleted, as the rest of those pointers :/

Apr 5, 2011 at 3:06 PM

Someone please mark this thread as closed (if possible).

I was able to find the memory leak. It turned out that the function got called twice because of a corrupt file
which i didnt expect.

 

I bow down before almighty VLD and feel deeply sorry for thinking it would fail when i was just blind!

:)