Yet another show stopping bug!!!
Zach Saw
{
return (x % 10);
}
void __fastcall TForm1::Button1Click(TObject *Sender)
{
for (int i=0; i<10000000; i++)
while (int Index = test("LEAKED DATA", i))
{
// doesn't matter if you do anything here
}
}
Each time EIP goes back to
while (int Index = test("LEAKED DATA", i))
during the while loop, "LEAKED DATA" is allocated, but never freed at the
end of the loop.
The for loop that does a few million times of the leak test is just to
amplify the problem so you could see it eating up your system memory.
This is a nastier bug than the previous show stopping bug I found just a
couple of weeks ago, where the compiler again generated incorrect codes.
This is clearly another Borland's C++ Compiler bug. If you declare int Index
while assigning it with the result of a function which requires a type cast
from char * to AnsiString, the compiler will allocate a temporary memory
space to hold the string pointed to by char *, and call the function.
However, the next time it comes back to the line, another temporary mem
space is allocated.
While the function "test" may be a useless function, you can try it with
AnsiString::Pos function and the result will still be the same.
Frankly, I'm very tired of doing system validation for Borland. I'm
curious --- one tiny bug from Intel (their Pentium floating point bug) and
the whole world screams product recall. Yet, so many easily reproduced bugs
from a compiler, and no one did anything about it??? And, what happened to
the consumer's rights? I've always thought people in the US do not take such
crap.
Can someone help me to verify this on their machine? We have reproduced this
on all the machines in our company using C++ Builder 6 update pack 4 with
latest ilink32. I'm surprised **AGAIN** such a bug is never reported, let
alone fixed!
BTW, does any one know the ratio of developer vs validation engineer in
Borland's product development team?
Zach Saw
can detect such a leak, such as memproof. Or, simply monitor the memory
usage of your application by using task manager (yeah I know most of you
will say it is not the best way to look for memory leaks, but in this case,
I don't think you'll even need anything to monitor -- just run the code and
wait for a few seconds, you'll be able to FEEL the memory leak).
And, just in case you want a more "correct" example, here it is
int __fastcall test(const AnsiString s, int x)
{
return (x % 10);
}
void __fastcall TForm1::Button1Click(TObject *Sender)
{
for (int i=0; i<10000000; i++)
{
int x = 9;
while (int Index = test("LEAKED DATA LEAKED DATA ...(copy and paste more
"LEAKED DATA" here) LEAKED DATA ", x))
x--;
}
}
The previous example will end up eating up all your system memory without
anyway you can stop it (other than CTRL+F2).
Andrue Cope [TeamB]
> Can someone help me to verify this on their machine? We have
> reproduced this on all the machines in our company using C++ Builder
> 6 update pack 4 with latest ilink32.
It's certainly doing something odd but Code Guard doesn't see it as a
leak. This *might* be because the allocation is going through the
Pascal Run Time Library. I'm never sure if/when that happens but
AnsiString could well be doing that.
I modified the code to put a termination clause in it:
for (int i=0; i<1000; i++)
{
int count=10;
while (int Index = test("LEAKED DATA", i)&&count)
{
--count;
// doesn't matter if you do anything here
}
}
..and there's a long delay before exiting which is usually indicative
of a leak.
> I'm surprised AGAIN such a bug is never reported, let alone fixed!
I'm not entirely surprised about it not being detected. Speaking as an
inveterant AnsiString user I have never come across this bug. I create
a lot of temporary AnsiStrings simply because it's such a flexible
class with so many ctors. For us not to have encountered this implies
that it's a rare bug. It also doesn't help that CG isn't seeing a leak
(although I /would/ be suspicious of a program that took several
seconds to terminate).
> Frankly, I'm very tired of doing system validation for Borland. I'm
> curious --- one tiny bug from Intel (their Pentium floating point
> bug) and the whole world screams product recall.
A lot more people use the Intel compiler. It is also widely regarded as
a benchmark. A bug in such a compiler is a big deal. For all it's
success (and BCB has been successful) few people regard it as a
benchmark. Most people regard it as a way to do RAD development while
staying with something pretty close to C++. A lot of us here only use
it for the GUI simply because that's the least critical part of an
application.
At one time people did hope it was a 100% compliant compiler but I
think now most of us are just glad we can use something approximating
C++ whilst retaining the benefits of RAD. Looked at as a C++
development environment BCB is okay but not particularly brilliant.
It's real benefit is access to the VCL without having to use Pascal.
> Yet, so many easily reproduced bugs from a compiler,
To be fair to BCB you've only found two of which this one seems to me
to be a corner case (although legitimate of course). I'll post it to
QC. If it's a VCL issue then it might have been fixed by a prior VCL
release (sadly BCB is a few years out of date there). If not the
developers might be able to sneak a fix into Dexter (the forthcoming
BCB/Delphi release).
> and no one did anything about it??? And, what happened to the
> consumer's rights? I've always thought people in the US do not take
> such crap.
Actually that's not true. Consumer law in the US isn't particularly
strong and nor (from what I've seen/heard) is quality. They seem to put
up with things Europeans wouldn't (but they pay less).
In any case this is software and for better or for worse software is
viewed more like a service than a good so comeback for the odd defect
is hard to get.
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html
Zach Saw
> I'm not entirely surprised about it not being detected. Speaking as an
> inveterant AnsiString user I have never come across this bug. I create
> a lot of temporary AnsiStrings simply because it's such a flexible
> class with so many ctors. For us not to have encountered this implies
> that it's a rare bug. It also doesn't help that CG isn't seeing a leak
> (although I /would/ be suspicious of a program that took several
> seconds to terminate).
You should perhaps try to use Memproof. This bug is 100% reproducable.
>
>> Frankly, I'm very tired of doing system validation for Borland. I'm
>> curious --- one tiny bug from Intel (their Pentium floating point
>> bug) and the whole world screams product recall.
>
> A lot more people use the Intel compiler. It is also widely regarded as
> a benchmark. A bug in such a compiler is a big deal. For all it's
> success (and BCB has been successful) few people regard it as a
> benchmark. Most people regard it as a way to do RAD development while
> staying with something pretty close to C++. A lot of us here only use
> it for the GUI simply because that's the least critical part of an
> application.
I was referring to the Intel Pentium processor floating point bug. I was a
validation engineer in Intel.
Also, it doesn't matter if BCB is not ANSI compliant. As long as it
generates correct code, I'm fine with it. The problem with it is that it has
caused us hundreds of hours debugging our code, just to find it is not our
fault. Small companies simply cannot afford that. It simply cancels out any
RAD advantage of BCB.
> To be fair to BCB you've only found two of which this one seems to me
> to be a corner case (although legitimate of course). I'll post it to
> QC. If it's a VCL issue then it might have been fixed by a prior VCL
> release (sadly BCB is a few years out of date there). If not the
> developers might be able to sneak a fix into Dexter (the forthcoming
> BCB/Delphi release).
I've already posted it to QC. Anyway, I've only reported 2 bugs so far but
all the other bugs I've managed to solve by changing the VCL source code and
making sure all our projects are compiled with the updated files. These are
the only 2 (and within a couple of weeks) that I am unable to do anything
besides changing the way we code. New hires come and go, and to train them
not to run into such a bug costs us recurring resource and money.
>> and no one did anything about it??? And, what happened to the
>> consumer's rights? I've always thought people in the US do not take
>> such crap.
>
> Actually that's not true. Consumer law in the US isn't particularly
> strong and nor (from what I've seen/heard) is quality. They seem to put
> up with things Europeans wouldn't (but they pay less).
>
> In any case this is software and for better or for worse software is
> viewed more like a service than a good so comeback for the odd defect
> is hard to get.
anyway, here's the report in QC:
Andrue Cope [TeamB]
> You should perhaps try to use Memproof. This bug is 100% reproducable.
I didn't say it wasn't. I merely pointed out that CG failed to spot it,
a bug (or at least limitation) of that particular tool. That just might
explain why few people have found that bug.
> It simply cancels out any RAD advantage of BCB.
I'm surprised that it's causing you that many problems tbh. It might be
the case that most people using the VCL tend to write simpler code and
as such don't encounter the more obscure bugs. I tend to do that simply
because I separate workhorse code from the GUI.
In this case that doesn't actually apply because AnsiString is too
useful (IMO) but AFAIK I've not seen this myself.
If BCB6 isn't delivering any significant advantages over other
development tools or causing you excessive stress I can only suggest
switching to another tool. I'm not trying to be funny but Borland's
track record with supporting BCB simply doesn't point to it being a
serious world standard C++ development environment.
It's a damn' fine RAD environment for C++ developers as I mentioned in
my last reply but beyond that it's not really up to the job. Personally
I'm confident that Dexter will offer me big improvements and be well
worth upgrading to but then most of the time BCB does what I want and
saves me time. From what you're posting here it seems that for some
reason BCB6 just isn't working for you and you are expecting a level of
support and commitment from Borland that I doubt will be forthcoming
unless you pay for it.
At least you are taking the time and trouble to report bugs and that's
very much appreciated. More so right now because Borland developers are
actively working on the project. I'd urge anyone with any issues to
make sure that they are reported via QC as soon as possible. Dexter
won't be in development for ever.
Zach Saw
I realised this is perhaps the wrong place for me to complain about BCB.
Just wanted to know there are other people who feel the same way about BCB.
I've heard Delphi 2006 will be released year end. No words on the release
date of Dexter though.
"Andrue Cope [TeamB]" <no....@not.a.valid.address> wrote in message
news:43424418$1...@newsgroups.borland.com...
Andrue Cope [TeamB]
> I realised this is perhaps the wrong place for me to complain about
> BCB. Just wanted to know there are other people who feel the same way
> about BCB.
>
A lot of us have gripes about BCB
(http://qc.borland.com/wc/qcmain.aspx?d=720 drives me up the wall on a
daily basis) but I /think/ most them relate to the IDE. A little more
conformance would be nice but in the occasional survey I've always said
that it's the IDE followed by the VCL that I want to see upgraded/fixed
(so you can probably blame me for the lack of compiler fixes <s>).
So far we've been lucky in that we have a lot of old code (our runtime
library is over 13 years old now). It's a double-edged sword in that
some of the code is stuff I wrote while learning C++ and therefore a
bit ugly. OTOH it means that most of it avoids the more 'clever' idioms
and templates which is where the compiler starts to look poor.
> I've heard Delphi 2006 will be released year end. No words on the
> release date of Dexter though.
They /should/ be one and the same thing. If anything the C++
personality would have appeared earlier as an update for Delphi 2005
but that's looking unlikely now (it never looked particularly likely
anyway). Borland are as usual tightlipped about release dates but my
feeling is that later this year is possible but Q1/2006 more likely.
What they need to do is improve the release quality because a lot of
people are fed up with getting a new release that's full of bugs (not
that we'd know anything about new releases, lol). I do know that they
are very focused on making this a high quality release but only time
will tell how successful they are.
Duane Hebert
"Zach Saw" <zs...@xtrimsoft.com> wrote in message
news:4342...@newsgroups.borland.com...
> int __fastcall test(const AnsiString s, int x)
> {
> return (x % 10);
> }
> void __fastcall TForm1::Button1Click(TObject *Sender)
> {
> for (int i=0; i<10000000; i++)
> while (int Index = test("LEAKED DATA", i))
> {
> // doesn't matter if you do anything here
> }
> }
This is very similar to something I've often seen
with AnsiString("whatever"). If you change your
code to:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
AnsiString spoo("LEAKED DATA");
for (int i=0; i<10000000; i++)
while (int Index = test(spoo, i))
{
// doesn't matter if you do anything here
}
}
Does this change the behavior?
Ed Mulroy
argument is not used and the compiler tells you that. Use it or change the
function to not take that calling argument.
. Ed
> Zach Saw wrote in message
> news:4342...@newsgroups.borland.com...
JD
"Andrue Cope [TeamB]" <no....@not.a.valid.address> wrote:
>
> [...] OTOH it means that most of it avoids the more 'clever'
> idioms [...]
Unless you're a company like M$ with a wealth of experties,
it's a bad choice anyway. With the rate of employee turn-over,
it's stupid to implement code that the next guy can't service.
~ JD
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> int __fastcall test(const AnsiString s, int x)
> {
> return (x % 10);
> }
> void __fastcall TForm1::Button1Click(TObject *Sender)
> {
> for (int i=0; i<10000000; i++)
> while (int Index = test("LEAKED DATA", i))
> {
> // doesn't matter if you do anything here
> }
> }
>
>
> Each time EIP goes back to
> while (int Index = test("LEAKED DATA", i))
> during the while loop, "LEAKED DATA" is allocated, but never freed at
> the end of the loop. The for loop that does a few million times of the
> leak test is just to amplify the problem so you could see it eating up
> your system memory.
Does it actually eat up system memory? AnsiStrings are managed by the
Delphi RTL, and are reference counted. They should take care of deleting
themselves. Perhaps that doesn't work properly in the C++ wrapper.
But I can hardly call it a show stopper, since a show stopper would stop
you from going on working at all. I can't see code like the above happen
very often. And as others have shown you, it is easy to work around it.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Whenever I climb I am followed by a dog called 'Ego'."
- Friedrich Nietzsche (1844-1900)
Andrue Cope [TeamB]
> > [...] OTOH it means that most of it avoids the more 'clever'
> > idioms [...]
>
> Unless you're a company like M$ with a wealth of experties,
> it's a bad choice anyway. With the rate of employee turn-over,
> it's stupid to implement code that the next guy can't service.
There is that. The cases Zach has posted probably don't fall into that
category but they go beyond what I'd call 'basic C++'. Unfortunately
they are also the worst kind of problems. At least when code doesn't
compile you know about it immediately and work around it. Code that
compiles and runs but quietly leaks memory is nasty.
I'm wondering now if the infamous 'fragmented heap' issue that has
plagued us occasionally over the years (currently not a problem AFAIK)
might not be the result of such bugs. At least our apps only need be
able to run for a few hours most of the time and a few days
occasionally. I really wouldn't like to have to write something with
24/7 uptime requirements using BCB.
Alan Bellingham
>might not be the result of such bugs. At least our apps only need be
>able to run for a few hours most of the time and a few days
>occasionally. I really wouldn't like to have to write something with
>24/7 uptime requirements using BCB.
I've done it. Or at least for quite long periods, and with BCB5.
My first rule - exile the VCL. Especially anywhere near COM. BCB5 can
cope quite happily with ATL, and the result is much much better IMO.
I _did_ find an interesting bug in the Perl Win32 source that caused a
leak of a few dozen bytes per instantiation of the Perl interpreter. By
the time I finished, I'd got the leak down to 1 bit per instantiation.
Yeah, I don't understand that either: I suspect it actually leaks 32
bytes once every 256 times, or something like that. But at least a leak
that slow allowed hundreds of millions of instantiations of the
interpreter, and that did take weeks even assuming 100 instantiations a
second.
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
Remy Lebeau (TeamB)
"Zach Saw" <zs...@xtrimsoft.com> wrote in message
news:4342...@newsgroups.borland.com...
> int __fastcall test(const AnsiString s, int x)
Try changing the parameter to a const reference and see if the problems
still persists:
int __fastcall test(const AnsiString &s, int x)
Gambit
Zach Saw
feeling a bit fed up with Borland after one week of debugging and root
causing the problem. :)
Anyway, I've already mentioned the correct workaround in my report in QC
(Please refer to http://qc.borland.com/wc/qcmain.aspx?d=19753).
This bug is related to the bug I found previously regarding a thrown
exception in ctor causes leak. RTL_DELPHIRETURN classes are handled
differently by the compiler.
Actually the best solution would be to stay away from RTL_DELPHIRETURN
classes like old times (i.e. C++ Builder 1), when I did not know anything
about C++ Builder specific libraries :)
Anyway, although it's not a show stopping bug for the compiler, it certainly
was a show stopping bug for the apps it has generated and deployed. And the
fact that codeguard did not catch it will lead most amatuers to think they
have created a solid app.
It's a real leak. At least my computer says it is :) I'm sure you guys have
much cooler tools to verify that :)
"Rudy Velthuis [TeamB]" <velt...@gmail.com> wrote in message
news:xn0e83fez295e...@www.teamb.com...
Zach Saw
anyway, I posted it here to let you guys know about the bug and the work
around, so no one will fall into this bug again. It doesn't matter if you
pass a ref, a pointer, or whatever... as long as it is criteria I mentioned
in the report, it will cause it to fail.
anyway, read the report.
"Remy Lebeau (TeamB)" <no....@no.spam.com> wrote in message
news:4342a562$1...@newsgroups.borland.com...
Wiljo
> Well, it's not a show stopper for the compiler, that's for sure. I was just
> feeling a bit fed up with Borland after one week of debugging and root
> causing the problem. :)
>
> Anyway, I've already mentioned the correct workaround in my report in QC
> (Please refer to http://qc.borland.com/wc/qcmain.aspx?d=19753).
>
Here is that workaround.
> declare Index first:
>int Index;
>while (Index = ...)
>
>However, this will cause the compiler to complain about a possible incorrect
>assignment.
>
But now the compiler generates a warning, and that is no good in my book. I must
say that I am surprised that only declaring the int outside the while statement
prevents that memory leak. I consider it best practice to declare any variables
just after the closest opening brace '{' of a compound statement, but never
inside an iterative loop.
I have also found that using AnsiString as arguments for functions causes some
memory leaks, and therefore we have written our own string class that doesn't
have a memory leak.
But to return to the workaround at hand. Although this works at run time, there
still is a compile time warning. A good workaround for this is in the comma
operator:
while( Index = ..., Index != 0 )
or applying parenthesis, whichever one finds handy (or legible):
while(( Index = ... ) != 0 )
What about this? The compiler will stop complaining, and code works as expected
without any problem.
Best Regards,
Wiljo.
AlexB
> hmm... starting to think no one actually reads my QC report :)
My comment for your previous report:
------------------------------------
>Do not pass let the compiler perform type cast on a parameter
>to a constructor if the parameter is a class declared with
>RTL_DELPHIRETURN. RTL_DELPHIRETURN classes
>are such as AnsiString, WideString, Currency etc.
The bug still exists if any temporary object with destructor goes as
parameter for constructor. Example (tested with BCB5 Up1):
class TDummy
{
public:
__fastcall TDummy(const char* p) {};
__fastcall ~TDummy(void) {};
}
class LeakMe
{
char leaked[10240000];
public:
__fastcall LeakMe(const TDummy& d) { throw 0; };
};
void __fastcall TForm1::Button1Click(TObject *Sender)
{
try
{
LeakMe*p=new LeakMe(TDummy("test"));
delete p;
}
catch (...) {}
}
Leak occures if TDummy has destructor. If this destructor is commented
out no leak occures.
So workaround is more strict:
Do not call constructor with temporary objects as parameter if temporary
object has destructor.
Or avoid any temporary objects at all...
-----------
Alex.
Zach Saw
RTL_DELPHIRETURN classes that causes the compiler to fail -- even a simple
class will cause a mem leak.
Anyway, tested it with BCB6 Up4 and it's still the same.
Thanks Alex.
"AlexB" <b....@inbox.ru> wrote in message
news:4343c4b1$1...@newsgroups.borland.com...
Zach Saw
RTL_DELPHIRETURN classes. This leads me to think those 2 bugs are totally
unrelated.
"AlexB" <b....@inbox.ru> wrote in message
news:4343c4b1$1...@newsgroups.borland.com...
Zach Saw
> plagued us occasionally over the years (currently not a problem AFAIK)
> might not be the result of such bugs. At least our apps only need be
> able to run for a few hours most of the time and a few days
> occasionally. I really wouldn't like to have to write something with
> 24/7 uptime requirements using BCB.
What should we use if one of the criteria is that the language must be C++?
Is MSVC better than C++ in terms of stability? I don't mind developing the
front ends using BCB, but for the rest of it, I'm looking for something more
solid. I guess I shouldn't have developed the server using BCB.
Andrue Cope [TeamB]
> What should we use if one of the criteria is that the language must
> be C++? Is MSVC better than C++ in terms of stability? I don't mind
> developing the front ends using BCB, but for the rest of it, I'm
> looking for something more solid. I guess I shouldn't have developed
> the server using BCB.
I'm not sure. If we had to switch we'd probably switch to VS.NET simply
because that's what the other half of our development team uses.
Historically VC hasn't been very standards compliant but the last
release seems to have addressed that.
As regards the quality of generated code I would guess that VS.NET is
very good solely because so many developers use it.
I wonder what other people will suggest though.
What with .NET sort of maybe catching on, a company takeover, DeXter,
our main project reaching a watershed, Windows Vista and Win64 it's
becoming an interesting topic for discussion here. You can never find a
crystal ball when you want one :-/