codeguard does not tetect vcl memory leaks?

[saabas]

hi,

we found a problem what codeguard seems not to detect leaks
when the object is VCL or TObject-derived
a simple example:
....
{
TObject *obj;
for(int i = 0; i<100; i++)
obj = new TObject;
}

You can put the code under some button click event, and click it several
times, and exit the program. All debug options and CodeGuard turned on -
not a single message about resource leaks in CG log window...

So the question is simple: For what is Codeguard good for? And how to
detect those leaks then?

[saabas]

and fyi, the CG thing was discovered with BCB5, but i think it is same
with BCB6

& sorry about the spelling error in subject ;)

[Andrue Cope]

Saabas,

> So the question is simple: For what is Codeguard good for? And how to
> detect those leaks then?
>

If you're using dynamic runtime library or packages try not doing. You
might also want to try deleting all the output (including the EXE/DLL)
and rebuilding.
--
Andrue Cope
[Bicester, UK]

Team Thai Kingdom

[saabas]

Andrue,

> If you're using dynamic runtime library or packages try not doing. You
> might also want to try deleting all the output (including the EXE/DLL)
> and rebuilding.
> --

ok, i recompiled whole thing without dynamic rtl and pkgs, and before
that i deleted .exe, obj's and precompiled headers too (in any case).
The result is same. VCL resource leaks are not noticed.

:(

If anyone can try that code and find what the leaks are noticed, i'd
like to hear about what project options they had...

[Andrue Cope]

Saabas,

I have duplicated this. I have proved that a normal C++ allocation
(new char[ 1000 ]) was being detected by CG so it would appear that
TObject is a special case. It would be worth asking in
VCL.COMPONENTS.USING in case as there appears to be something
special about TObject. Having stepped through the library code it
looks like it might be adding the object to an internal list.

If that's true then it means the object could be being cleared up on
program exit.

OTOH another explanation is that the object is being allocated
through Pascal code which might be circumenting Code Guard.

[saabas]

Andrue Cope ::

we found that memory management of VCL objects is totally different from
pure C++ objects. For C++ objects global operator new is used, but for
VCL objects SysGetMem function is used, see functions GetMemoryManager
and SetMemoryManager from online help. Further it seems that CG does
report correctly all memory leaks when using debug libraries (of VCL,
see Project Options | Linker | Use debug libraries).
But that option does not work for dynamically linked packages.

Hmm, so i have to write my own memory manager... ;-)

[Andrue Cope]

Saabas,

> Further it seems that CG does
> report correctly all memory leaks when using debug libraries (of VCL,
> see Project Options | Linker | Use debug libraries).
> But that option does not work for dynamically linked packages.
>

Sounds like it needs reporting on Quality Central..

[Russell Hind]

"Andrue Cope" <not.a...@email.address.sorry> wrote in message
news:VA.0000174...@email.address.sorry...

>
> > Further it seems that CG does
> > report correctly all memory leaks when using debug libraries (of VCL,
> > see Project Options | Linker | Use debug libraries).
> > But that option does not work for dynamically linked packages.
> >
>

From what I can remember of discussions on the groups from when BCB5 came
out, CodeGuard doesn't work with VCL classes because or the way they are
allocated using SysGetMem rather than New. Probably partly due to the fact
that Delphi doesn't have CodeGuard or an equivelant. Wow, something we have
that they don't!!!!

Russell

[Andrue Cope]

Russell Hind,

> Probably partly due to the fact
> that Delphi doesn't have CodeGuard or an equivelant.
>

Promised in D7 apparently. Imagine those poor innocent Delphi
programmers suddenly being confronted with CG. I hope they tone the
messages down a bit or they'll all be in tears :)

[Josh Green]

> From what I can remember of discussions on the groups from when BCB5 came
> out, CodeGuard doesn't work with VCL classes because or the way they are
> allocated using SysGetMem rather than New.

This makes sense, The more I click the button, the more calls to sysGetMem
are logged by codeguard. But the amount of times the SysFreeMem are called
doesn't change at all.

No Clicks of the button:
Functions called:
delete (35 times)
SysFreeMem (314 times)
SysGetMem (314 times)

1 Click:
Functions called:
delete (35 times)
SysFreeMem (314 times)
SysGetMem (324 times)

5 Clicks:
Functions called:
delete (35 times)
SysFreeMem (314 times)
SysGetMem (364 times)

I've only got it looping through 10 times
So yeah, it looks like a memory leak.
--Josh

[Alex Bakaev [TeamB]]

Andrue Cope wrote:
> Saabas,
>
> I have duplicated this. I have proved that a normal C++ allocation

[snip]

Memory for VCL objects is allocated by the VCL memory manager that CG
doesn't know about, unfortunately.

.a

[Duane Hebert]

Same thing for TStringList - Memproof picks up on it though...

[Andrue Cope]

Alex Bakaev [TeamB],

> Memory for VCL objects is allocated by the VCL memory manager that CG
> doesn't know about, unfortunately.
>

Thanks for confirming that - it looked like that might be the case.

[Duane Hebert]

> > Memory for VCL objects is allocated by the VCL memory manager that CG
> > doesn't know about, unfortunately.
> >
>
> Thanks for confirming that - it looked like that might be the case.

It's good to get confirmation of this but in that case, what is Borland's
recommendation for debugging VCL?

[Alex Bakaev [TeamB]]

There are 3rd party tools, one from TurboPower and one written by Atanas
Stoyanov (MemProof?).

.a

[Duane Hebert]

> There are 3rd party tools, one from TurboPower and one written by Atanas
> Stoyanov (MemProof?).

We use MemProof and it's pretty well done. My question was more about
whether Borland thought it a good idea to not supply a debugger as part of
their IDE. Maybe they should work out a deal with Atanas...