CodeGuard wierdness
Fishface
TStringList *sl = new TStringList;
sl->Text = "Some Text.\nSome More Text.";
ShowMessage(sl->Strings[1]);
...but it does catch this "resource mismatch"
immediately upon execution:
char *c = new char[4096];
delete c; // not using delete[]
...and it catches this as a leak when the application
closes:
char *d = new char[4096];
(just testing it to make sure is is otherwise operational)
Since TStringList doesn't have an owner, shouldn't
CodeGuard complain about not deleting it?
Duane Hebert
news:3e76...@newsgroups.borland.com...
Code guard doesn't seem to catch failures to free TStringList. I think it
may be the same with anything derived from TComponent but I'm not sure, nor
am I sure what the exact reasons are. Maybe Remy or one of the other VCL
experts can explain. We've been using Memory Sleuth due to this. It seems
to work fine in both cases as long as you do a straight debug build ( no run
time packages and no dynamic RTL). I don't know if Turbopower has open
sourced it yet though. Memproof will also catch this but it's a bit harder
to configure.
Fishface
> Code guard doesn't seem to catch failures to free TStringList. I
> think it may be the same with anything derived from TComponent
> but I'm not sure, nor am I sure what the exact reasons are.
TStringLists anscestors are TObject and TPersistent. I tried it with
TBitmap with the same result. It may be a Delphi base class thing.
Well, that certainly limits it's usefulness. The false sense of security
could bite you in the ass, easily. Well, it's certainly something of
which to be aware.
> Maybe Remy or one of the other VCL experts can explain.
> We've been using Memory Sleuth due to this. It seems to work
> fine in both cases as long as you do a straight debug build ( no
> run time packages and no dynamic RTL). I don't know if
> Turbopower has open sourced it yet though. Memproof will
> also catch this but it's a bit harder to configure.
Ok, thanks. I think I have a Memory Sleuth disk kicking
around that I got free with an upgrade. I'm not sure if it will
work with later versions of BCB, though...
Sebastian Moleski
news:3e76...@newsgroups.borland.com...
>
> > Code guard doesn't seem to catch failures to free TStringList. I
> > think it may be the same with anything derived from TComponent
> > but I'm not sure, nor am I sure what the exact reasons are.
>
> TStringLists anscestors are TObject and TPersistent. I tried it with
> TBitmap with the same result. It may be a Delphi base class thing.
> Well, that certainly limits it's usefulness. The false sense of security
> could bite you in the ass, easily. Well, it's certainly something of
> which to be aware.
If you could, please post a bug report at QC. It is indeed true that
CodeGuard doesn't work well (i.e. at all) with classes derived from TObject.
I would attribute that to the way, Delphi memory handling interferes with
BCB's.
sm
Fishface
> If you could, please post a bug report at QC. It is indeed
> true that CodeGuard doesn't work well (i.e. at all) with
> classes derived from TObject. I would attribute that to
> the way, Delphi memory handling interferes with BCB's.
It seems that this has been previously encountered:
http://groups.google.com/groups?threadm=3da420fc%241%40newsgroups.borland.com
...but I couldn't find mention on QC.
Fishface
> If you could, please post a bug report at QC. It is indeed
> true that CodeGuard doesn't work well (i.e. at all) with
> classes derived from TObject.
Oh, do you know what? I am still using BCB5-- I should
have specified. I keep forgetting I am years from state-of-
the-art in design tools. I'm sure that if I reported it as a
BCB5 bug, it would get lots of attention!
Duane Hebert
> Oh, do you know what? I am still using BCB5-- I should
> have specified. I keep forgetting I am years from state-of-
> the-art in design tools. I'm sure that if I reported it as a
> BCB5 bug, it would get lots of attention!
We're still using BCB5 as well. This was a fairly annoying find for us. It
seems ridiculous that Borland would ship a debugging tool that didn't work
with its native VCL stuff. Additionally, there is no mention of this
anywhere in the documentation that I could find. When testing a release
build of our app, I was getting access violations. Code guard was fat, dumb
and happy. By tracing through the code I found the problem and it turned
out to be a String list that was not getting deleted. Now we use codeguard,
memproof and memory sleuth before releasing anything. As you say, I doubt
if they're going to do anything to fix BCB5. We're wating for BCB6 to get
more stable and then we'll probably updgrade.
Mario Alvares
"Fishface" <mailto:inv...@ddress.ok> wrote in message
news:3e76...@newsgroups.borland.com...
> It lets me do this:
>
> TStringList *sl = new TStringList;
> sl->Text = "Some Text.\nSome More Text.";
> ShowMessage(sl->Strings[1]);
> Since TStringList doesn't have an owner, shouldn't
> CodeGuard complain about not deleting it?
Codeguard does catch the leak when you:
1) Build without runtime packages (Packages tab)
2) Use debug libraries (Linker tab).
Mario
Fishface
> Codeguard does catch the leak when you:
>
> 1) Build without runtime packages (Packages tab)
> 2) Use debug libraries (Linker tab).
Yes, good deal, thanks. I was experimenting with some
optimizations and un-checked debug libraries option. I
was not aware of the side-effect. Still, it is good to know
what is necessary...
Duane Hebert
"Fishface" <inv...@ddress.ok?> wrote in message
> Mario Alvares wrote:
>
> > Codeguard does catch the leak when you:
> >
> > 1) Build without runtime packages (Packages tab)
> > 2) Use debug libraries (Linker tab).
Yep. That does seem to work.