SHOW STOPPING memory leak bug in C++ Builder

[Zach Saw]

Folks,

This is a show stopper!!!
Create an empty project, and throw a button on the form.

And copy and paste this code to the cpp file:

class LeakMe
{
char leaked[10240000];
public:
__fastcall LeakMe(const AnsiString &str)
{
throw Exception("LEAKED!");
}
};

and in your buttonclick handler:

for (int i=0; i<1000000; i++)
{
try
{
new LeakMe("test");
}
catch (const Exception &e)
{
}
}

Compile and run this without the IDE (i.e. run the exe file).
You'll have Windows complaining low virtual memory in seconds (open task
manager and watch out for the virtual memory used column).

However, if we do it this way:

for (int i=0; i<1000000; i++)
{
try
{
AnsiString test = "test";
new LeakMe(test);
}
catch (const Exception &e)
{
}
}

Then there won't be any leaks!

*** PUZZLED *** !!!!!
What is going on inside AnsiString? Who is the culprit?

Please help.

By the way, I want my money back for all the copies of the BCB6 we've bought
if this is not solved ASAP!

[Andrue Cope [TeamB]]

Post by Zach Saw
This is a show stopper!!!

That's unfortunate since BCB6 has been on sale and in use around the
world for several years now.

Post by Zach Saw
for (int i=0; i<1000000; i++)
{
try
{
new LeakMe("test");
}
catch (const Exception &e)
{
}
}

That will certainly leak. Exactly how much it leaks depends how much
memory Windows is prepared to let your application have. Given that you
are attempting to allocate several TB of memory I'd be somewhat leary
of being more precise. There's no way Windows can possible honour the
requests being made of it so exactly what will happen is hard to
predict. It's in the lap of the Microsoft gods.

Post by Zach Saw
try
{
AnsiString test = "test";
new LeakMe(test);
}

The addition of the AnsiString should make no difference. Well -
technically it /could/ be enough to influence the point at which the
program hiccups but in practice I doubt if it will.

For completeness' sake I have carried out tests using more reasonable
memory amounts and the results are what I expected. Every successful
construction of the class leaks whatever memory is required to hold its
data members.

Post by Zach Saw
You'll have Windows complaining low virtual memory in seconds (open
task manager and watch out for the virtual memory used column).

A complaint about low memory does not neccessarily indicate a leak. A
'memory leak' is when memory allocated during processing is not
deallocated at process end. Simply asking for too much memory is not
automatically a memory leak.

You should also be very wary of using Windows Task Manager to monitor
memory usage. It isn't very accurate and it can't report on what the
Borland Heap Manager is actually doing. By this I mean that a call to
'new' does not neccessarily result in a call to Windows to allocate
memory although with large memory blocks it probably will. Note that
this raises another issue. If every call to 'new' is resulting in a
call to Windows then you are asking for more discrete memory blocks
than Windows can provide. It can only provide 65,535 blocks per program.

One thing puzzles me. Are you expecting a leak or not? Both examples
should leak - are you expecting otherwise?

Post by Zach Saw
By the way, I want my money back for all the copies of the BCB6 we've
bought if this is not solved ASAP!

Are you serious or this is an attempt at humour?

[Zach Saw]

Post by Andrue Cope [TeamB]
That will certainly leak. Exactly how much it leaks depends how much
memory Windows is prepared to let your application have. Given that you
are attempting to allocate several TB of memory I'd be somewhat leary
of being more precise.

I was attempting to allocate 10Mb of memory (10240000 bytes, simple
calculation gives you 9.765625Mb). It'll still be the same if you try to
allocate 1 byte.

There's no way Windows can possible honour the

Post by Andrue Cope [TeamB]
requests being made of it so exactly what will happen is hard to
predict. It's in the lap of the Microsoft gods.

Windows can't possibly allocate 10Mb of memory??? You got me there!

Post by Andrue Cope [TeamB]
The addition of the AnsiString should make no difference. Well -
technically it /could/ be enough to influence the point at which the
program hiccups but in practice I doubt if it will.
For completeness' sake I have carried out tests using more reasonable
memory amounts and the results are what I expected. Every successful
construction of the class leaks whatever memory is required to hold its
data members.

A construction of a class is only considered successful when the constructor
code is completely executed. When an exception occurs in a constructor, the
construction of the object is considered to be incomplete, thus destructor
will not be called, but stack will be unrolled.

So you are agreeing with me that this IS indeed a show stopper then. There
should be no leak of memory in the example. If there is another way of
freeing up the leaked memory, please enlighten me.

Post by Andrue Cope [TeamB]
A complaint about low memory does not neccessarily indicate a leak. A
'memory leak' is when memory allocated during processing is not
deallocated at process end. Simply asking for too much memory is not
automatically a memory leak.

I was creating the example so that people who do not have codeguard will be
able to see the leak as well.
And AGAIN, 10Mb is NOT too much memory! Try enabling codeguard and tell me
codeguard is wrong as well.

Post by Andrue Cope [TeamB]
You should also be very wary of using Windows Task Manager to monitor
memory usage. It isn't very accurate and it can't report on what the
Borland Heap Manager is actually doing. By this I mean that a call to
'new' does not neccessarily result in a call to Windows to allocate
memory although with large memory blocks it probably will. Note that
this raises another issue. If every call to 'new' is resulting in a
call to Windows then you are asking for more discrete memory blocks
than Windows can provide. It can only provide 65,535 blocks per program.

Forget Task Manager -- turn on Codeguard.

Post by Andrue Cope [TeamB]
One thing puzzles me. Are you expecting a leak or not? Both examples
should leak - are you expecting otherwise?

One does, the other does not. But, they both SHOULD NOT. Did you try the
other one? Again, turn on codeguard. It's there for a reason.

Post by Andrue Cope [TeamB]

Post by Zach Saw
By the way, I want my money back for all the copies of the BCB6 we've
bought if this is not solved ASAP!

Are you serious or this is an attempt at humour?

What do you think?

BTW, BCB version is 6, update pack 4, latest ilink32.

[Andrue Cope [TeamB]]

Post by Zach Saw
Windows can't possibly allocate 10Mb of memory??? You got me there!

You are indeed allocating 10MB chunks of memory (please, note the
capital 'B' for byte - 'b' means bit <s>) /but you are allocating

Post by Zach Saw
for (int i=0; i<1000000; i++)
{
try
{
new LeakMe("test");
}
catch (const Exception &e)
{
}
}

Do you see a call to 'delete' anywhere in there? I don't. Every pass of
that loop allocates 10MB to hold an instance of 'LeakMe'. Eventually
you will either run out of memory or memory handles. At that point in
an ideal world the loop should exit. If the program is then closed
there will be a runtime manager leak of however much memory was
succesfully allocated. Of course when Windows finally removes the
process from memory the leaked storage will be claimed back but that
doesn't excuse the wilful disregard of new/delete pairing demonstrated
here.

In practice I have doubts about Windows' ability to perform correctly
when placed in a low memory condition. I'm not a C++ expert but I think
this is in implementation issue and the exact consequences of your
example are therefore undefined.

Post by Zach Saw
When an exception occurs in a constructor, the construction of the
object is considered to be incomplete, thus destructor will not be
called, but stack will be unrolled.

In your example the /only/ time the destructor will be called is on a
failed allocation. Each successful allocation in your example leaves
the object on the heap without anything pointing to it - a classic,
run-of-the-mill, text book memory leak. The kind of thing C++ (and in
fact any language) instructor will drill into the heads of anyone they
are teaching.

If you want to test the ability of BCB6 to call the destructor as you
seem to expect it to then put the class on the stack:

for (int i=0; i<1000000; i++)
{
try
{
LeakMe noLongerALeak("test");
}
catch (const Exception &e)
{
}
}

This will not leak memory, nor run out of memory. The destructor will
be called as often as the constructor.

Post by Zach Saw
One does, the other does not. But, they both SHOULD NOT.

Since when? Every call to 'new' must be matched by a call to 'delete'.
That is a fundamental aspect of the C++ language and has been since its
conception.

Post by Zach Saw

Post by Andrue Cope [TeamB]
Are you serious or this is an attempt at humour?

What do you think?

I don't know, that's why I asked.

You accuse a stable, elderly, established development tool of being
unable to comply with a fundamental characteristic of the C++ language.
Then you make a veiled threat about demanding money back.

I'm genuinely not sure at this stage what to make of your posts but I
continue to reply in the hope that we will eventually come to a
sensible resolution.

[Alisdair Meredith [TeamB]]

Post by Andrue Cope [TeamB]
Do you see a call to 'delete' anywhere in there? I don't.

Nor is one needed for this specific test case!

Take another look at the constructor - it throws. No objects are
successfully constructed so all resources should be reclaimed, but no
destructors run (if one had been declared)


AlisdairM(TeamB)

[Andrue Cope [TeamB]]

Post by Alisdair Meredith [TeamB]

Post by Andrue Cope [TeamB]
Do you see a call to 'delete' anywhere in there? I don't.

Nor is one needed for this specific test case!
Take another look at the constructor - it throws. No objects are
successfully constructed so all resources should be reclaimed, but no
destructors run (if one had been declared)

Gah! You're right. I had exceptions disabled.

[Zach Saw]

Thank YOU!!!

I was getting disappointed with TeamB. I hope mine is the only isolated case
where borland users are treated as if they're all noobs.


"Alisdair Meredith [TeamB]"

Post by Alisdair Meredith [TeamB]

Post by Andrue Cope [TeamB]
Do you see a call to 'delete' anywhere in there? I don't.

Nor is one needed for this specific test case!
Take another look at the constructor - it throws. No objects are
successfully constructed so all resources should be reclaimed, but no
destructors run (if one had been declared)
AlisdairM(TeamB)

[Zach Saw]

Post by Andrue Cope [TeamB]
You are indeed allocating 10MB chunks of memory (please, note the
capital 'B' for byte - 'b' means bit <s>) /but you are allocating

Try to run the one that does NOT leak -- the second code snippet in my
original mail.
Do you even know how C++ works?

Post by Andrue Cope [TeamB]
Do you see a call to 'delete' anywhere in there? I don't. Every pass of
that loop allocates 10MB to hold an instance of 'LeakMe'. Eventually
you will either run out of memory or memory handles. At that point in
an ideal world the loop should exit. If the program is then closed
there will be a runtime manager leak of however much memory was
succesfully allocated. Of course when Windows finally removes the
process from memory the leaked storage will be claimed back but that
doesn't excuse the wilful disregard of new/delete pairing demonstrated
here.
In practice I have doubts about Windows' ability to perform correctly
when placed in a low memory condition. I'm not a C++ expert but I think
this is in implementation issue and the exact consequences of your
example are therefore undefined.

A throw inside a constructor constitute to an incomplete instantiation of
object. No delete is required. In fact, you will not even get a pointer to
the object, because it is not supposed to exist. Without a pointer to the
object, do enlighten me how you intend to delete the object.

Post by Andrue Cope [TeamB]

Post by Zach Saw
When an exception occurs in a constructor, the construction of the
object is considered to be incomplete, thus destructor will not be
called, but stack will be unrolled.

In your example the /only/ time the destructor will be called is on a
failed allocation. Each successful allocation in your example leaves
the object on the heap without anything pointing to it - a classic,
run-of-the-mill, text book memory leak. The kind of thing C++ (and in
fact any language) instructor will drill into the heads of anyone they
are teaching.

Let's be constructive here. I'm not sure how your insults are helping us to
solve the issue.
Also, talking about C++, do you even know how an exception inside a
constructor is supposed to be handled (ANSI speaking)?
I gave you the benefit of the doubt, expecting to talk to an expert in C++.
But it seems I'm talking to someone who is highly defensive and highly
unconstructive.

Post by Andrue Cope [TeamB]
If you want to test the ability of BCB6 to call the destructor as you
for (int i=0; i<1000000; i++)
{
try
{
LeakMe noLongerALeak("test");
}
catch (const Exception &e)
{
}
}
This will not leak memory, nor run out of memory. The destructor will
be called as often as the constructor.

This is where I should drill into your head. Destructor is NEVER called for
constructors that throw exception. Please, if you don't know C++, don't
reply.

Post by Andrue Cope [TeamB]

Post by Zach Saw
One does, the other does not. But, they both SHOULD NOT.

Since when? Every call to 'new' must be matched by a call to 'delete'.
That is a fundamental aspect of the C++ language and has been since its
conception.

Since the introduction of exception handling in C++. One which you clearly
hasn't learned.

Post by Andrue Cope [TeamB]
You accuse a stable, elderly, established development tool of being
unable to comply with a fundamental characteristic of the C++ language.
Then you make a veiled threat about demanding money back.
I'm genuinely not sure at this stage what to make of your posts but I
continue to reply in the hope that we will eventually come to a
sensible resolution.

I'm hoping to get a solution out of this. I have been using C++ Builder
since the first incarnation. I LOVE C++ Builder and I sincerely do not wish
to see anyone turning their back on it. That is why I am bringing this issue
up. Learn to give Borland users benefit of the doubt. Some of us happen to
be highly experienced and professional C++ programmers.

[Andrue Cope [TeamB]]

Post by Zach Saw
Let's be constructive here. I'm not sure how your insults are helping
us to solve the issue. Also, talking about C++, do you even know how
an exception inside a constructor is supposed to be handled (ANSI
speaking)?

I'm sorry if the tone of my reply offended you but it wasn't meant that
way. Unfortunately the test case I normally use had Delphi exceptions
disabled and I somehow missed the manually thrown exception when
parsing the code by eye.

Post by Zach Saw
I gave you the benefit of the doubt, expecting to talk to an expert
in C++. But it seems I'm talking to someone who is highly defensive
and highly unconstructive.

Unfortunately being a member of TeamB doesn't mean that I am perfect.
We all make mistakes from time to time. I do however take exception to
you saying I was defensive or unconstructive. I saw what I believed at
the time to be the problem and I continued the discussion in order to
obtain more information.

[John G Harris]

In article <43201b39$***@newsgroups.borland.com>, Zach Saw
<***@hotmail.com> writes

<snip>

Post by Zach Saw
Some of us happen to
be highly experienced and professional C++ programmers.

In which case you will know that Borland's warranty guarantees you will
get a readable CD.

Nothing else.

At all.

John

[Duane Hebert]

Post by Andrue Cope [TeamB]

Post by Zach Saw
Windows can't possibly allocate 10Mb of memory??? You got me there!

You are indeed allocating 10MB chunks of memory (please, note the
capital 'B' for byte - 'b' means bit <s>) /but you are allocating

Post by Zach Saw
for (int i=0; i<1000000; i++)
{
try
{
new LeakMe("test");
}
catch (const Exception &e)
{
}
}

Do you see a call to 'delete' anywhere in there? I don't. Every pass of
that loop allocates 10MB to hold an instance of 'LeakMe'. Eventually

?? In c++ new is guaranteed to do nothing when a ctor doesn't
complete. The ctor throws here so nothing should be constructed
and there should be no leak. I wouldn't rely on task manager though.
What does codeguard say?

[Andrue Cope [TeamB]]

Post by Duane Hebert
?? In c++ new is guaranteed to do nothing when a ctor doesn't
complete.

Yes, quite correct. My test project had Delphi exceptions turned off
and I missed the explicit throw.

[Alisdair Meredith [TeamB]]

Post by Duane Hebert
?? In c++ new is guaranteed to do nothing when a ctor doesn't
complete.

Not quite, but close <g>
If construction fails, new will hand back its resources - but can still
have effected internal changes in the memory manager. To all intents
and purposes it should not be observable, but as an example - memory
fragmentation is still a permitted behaviour, as is logging of the
calls etc.

AlisdairM(TeamB)

[Duane Hebert]

"Alisdair Meredith [TeamB]"

Post by Alisdair Meredith [TeamB]

Post by Duane Hebert
?? In c++ new is guaranteed to do nothing when a ctor doesn't
complete.

Not quite, but close <g>
If construction fails, new will hand back its resources - but can still
have effected internal changes in the memory manager. To all intents
and purposes it should not be observable, but as an example - memory
fragmentation is still a permitted behaviour, as is logging of the
calls etc.

I was speaking wrt the object creation. I wasn't aware that c++ made
any guarantees about memory managers. My point is that this is
definitely a bug. We've had the same result here. FWIW, I don't
think the bug is with new(). It seems to me that it's a bug with the
ctor for ansistring that takes a const char. I think that if you create
the ansistring first and pass that to the ctor that this doesn't show
up. We've had similar problems when passing ansistrings between
threads.

[Zach Saw]

you are right. If you create an ansistring first, problem goes away. How a bug in ansistring causes such catastrophic failure in the memory manager is beyond me though.

It seems to me that it's a bug with the

Post by Duane Hebert
ctor for ansistring that takes a const char. I think that if you create
the ansistring first and pass that to the ctor that this doesn't show
up. We've had similar problems when passing ansistrings between
threads.

[Chris Uzdavinis (TeamB)]

Post by Zach Saw
you are right. If you create an ansistring first, problem goes
away. How a bug in ansistring causes such catastrophic failure in
the memory manager is beyond me though.

My guess is that the local variable is triggering the code-generator
to behave differently, and generate a "cleanup" block that for
whatever reason, isn't being generated in the example you provided.

Codegen bugs can be tickled by the strangest things.

[Duane Hebert]

Post by Zach Saw
you are right. If you create an ansistring first, problem goes away. How a

bug in ansistring causes such catastrophic failure in the memory manager is
beyond me though.

Not sure how a bug in AnsiString does this. Delphi has
different rules than c++, specically wrt construct/destruct
order etc. In Delphi, the destruct order starts with the
base and propagates down. In c++, of course, it's the
opposite.

We've had myriad problems with this in our
own code. It's especially interesting when you have
both delphi objects and c++ objects in the food chain
(like deriving from class that is derived from TForm)

Maybe it's something similar though that's only a guess.
Without really knowing what causes these kinds of bugs,
the best that we could do is to try to isolate the
behavior that invokes them and avoid that.


The TeamB guys in this thread can probably give you
a better idea of what causes this, though I don't know
of any work arounds other than to prevent the situation
where it happens.

You should probably also take a look at the reports
in QC. Don't restrict yourself to BCB6 though as
some of these have been around a while...

[Andrue Cope [TeamB]]

Post by Zach Saw
One does, the other does not. But, they both SHOULD NOT. Did you try
the other one? Again, turn on codeguard. It's there for a reason.

A colleague has just suggested that perhaps you are a C# developer that
has just moved to C++? I think that in C# (assuming it even compiles)
there would be no leak since C# has garbage collection. C++ does not
have garbage collection (which a lot of us are grateful for).

[Zach Saw]

No I'm not a C# programmer and I've been doing C++ for 15 years, way before
Borland produced C++ Builder and I have no clue what C# is except that it's
by Microsoft.

Anyway, did you try the other example? The one that does not leak? Or try
this:

This one does not leak any memory, and you can run it over a million times
and it will still not crash.

class LeakMe : TObject
{
char * test;
char leaked[10240000];
public:
__fastcall LeakMe(const AnsiString &str)
{
throw Exception("No longer leaked");
}
};

try
{
new LeakMe("test");
}
catch (const Exception &e)
{
}

Can someone from Borland reply? This bug needs someone who understands C++.

[Andrue Cope [TeamB]]

Post by Zach Saw
No I'm not a C# programmer and I've been doing C++ for 15 years, way
before Borland produced C++ Builder and I have no clue what C# is
except that it's by Microsoft.

Yes, you're right.

I had exceptions disabled on my test project. I'm very sorry about
that. That'll teach me to look at the code a bit more carefully.

[Zach Saw]

Now we've got the unconstructive stuff out of the way, let me just add that
it only happens when you pass an AnsiString (as reference or not) into the
constructor. Haven't extensively tried other classes though.

Post by Andrue Cope [TeamB]

Post by Zach Saw
No I'm not a C# programmer and I've been doing C++ for 15 years, way
before Borland produced C++ Builder and I have no clue what C# is
except that it's by Microsoft.

Yes, you're right.
I had exceptions disabled on my test project. I'm very sorry about
that. That'll teach me to look at the code a bit more carefully.
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

[Zach Saw]

Well, we'll need to carry on with our projects. How do I workaround this
problem?

Post by Zach Saw
Now we've got the unconstructive stuff out of the way, let me just
add that it only happens when you pass an AnsiString (as reference or
not) into the constructor. Haven't extensively tried other classes
though.

Well at least it gives us a test case for future versions of the
compiler.
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

[Duane Hebert]

Post by Zach Saw
Well, we'll need to carry on with our projects. How do I workaround this
problem?

I can tell you what we've done to alleviate some of these problems:

Clear separation between GUI and non GUI stuff (treating AnsiString
as GUI stuff). This limits the cases where AnsiStrings get constructed
from const char*.

Try to control which AnsiString ctors are called. For example, create the
Ansistring explicitly to pass to the ctor.

Use STL for everything that's not directly GUI related with an interface
between the two to handle conversions.

Use boost::format and std::string to replace AnsiString
wherever possible.

Use std::vector<std::string> to replace TStringList wherever
possible.

This all adds complexity and reduces the RAD value of BCB
but we've found that we spend more time tracking down the
sort of bugs that you describe than the time we were saving.

Hopefully, Dexter will solve some of these problems. Even
so, separating the GUI stuff is basically a good design strategy
IMO.

[Chris Uzdavinis (TeamB)]

Post by Zach Saw
Well, we'll need to carry on with our projects. How do I workaround this
problem?

You earlier said that it only seems to happen if you pass AnsiStrings
into the constructor. How about passing char const * instead?

[Zach Saw]

The problem is, we do not have enough resources to change over 5 years of C++ Code to do that. Releasing the updated binary of our products would already be costly enough for a small company like ours. A few of our clients are facing this problem and it took us nearly 3 months now to minimize it until this. I am not sure how long this problem has been there, and how wide this problem spreads, but just recently we were engaged in a project with Komag USA. And due to this problem, they are facing a crash in the pre-deployment server every 2 days.

You have to admit this is a bug that is highly reproducable and potentially affects a high percentage of BCB built applications out there.

Anyway, the bottomline is, we do not have the ability to revamp our code that has been the collective effort of over 5 years by the whole team.

Post by Chris Uzdavinis (TeamB)

Post by Zach Saw
Well, we'll need to carry on with our projects. How do I workaround this
problem?

You earlier said that it only seems to happen if you pass AnsiStrings
into the constructor. How about passing char const * instead?
--
Chris (TeamB);

[Chris Uzdavinis (TeamB)]

Post by Zach Saw
The problem is, we do not have enough resources to change over 5
years of C++ Code to do that. Releasing the updated binary of our

Well, you were asking for a workaround, and I was answering in that
context.

I don't have BCB handy to test this out, but I wonder if you
explicitly override operator delete for that class (to call the global
operator delete as would normally happen), perhaps that will change
things?

Seems much less effort than changing all the callers creating
instances of this class. (But I'm not sure if that'll actually help
or not.)

[Alex Bakaev [TeamB]]

What about trying to change the compiler code generation options? I.E.,
change the processor type, disable inline methods, disable/enable
debugging. Any one of these things might help.

.a

[Zach Saw]

Changing those have no effect on the problem.

Post by Alex Bakaev [TeamB]
What about trying to change the compiler code generation options? I.E.,
change the processor type, disable inline methods, disable/enable
debugging. Any one of these things might help.
.a

[Ed Mulroy]

Please double check on if flipping the disable inline expansions options has
no effect.

. Ed

Post by Zach Saw
Changing those have no effect on the problem.

Post by Alex Bakaev [TeamB]
What about trying to change the compiler code generation
options? I.E., change the processor type, disable inline
methods, disable/enable debugging. Any one of these things
might help.

[Zach Saw]

No effects whatsoever. Confirmed.

Post by Ed Mulroy
Please double check on if flipping the disable inline expansions options
has no effect.
. Ed

Post by Zach Saw
Changing those have no effect on the problem.

Post by Alex Bakaev [TeamB]
What about trying to change the compiler code generation
options? I.E., change the processor type, disable inline
methods, disable/enable debugging. Any one of these things
might help.

[Andrue Cope [TeamB]]

Post by Zach Saw
Now we've got the unconstructive stuff out of the way, let me just
add that it only happens when you pass an AnsiString (as reference or
not) into the constructor. Haven't extensively tried other classes
though.

Well at least it gives us a test case for future versions of the
compiler.

[Alisdair Meredith [TeamB]]

Post by Zach Saw
*** PUZZLED *** !!!!!
What is going on inside AnsiString? Who is the culprit?
Please help.

This is a very puzzling bug and drove me nuts for years trying to pin
it down. I have done quite a lot of research on BCB destructor bugs
over the years, and there are a few reports in Quality Central that
might help.

The basic advice is 'disable inline functions'. Most of the leak bugs
come from bad code generating expanding constructors/destructor inline.
Without this optimisation I think you will get correct code.

The second advice is 'be alert'. There are still problems when base
classes and data member constructors throw exceptions, and these can
lead to even nastier code generation bugs. I have resorted to 2-phase
construction in several parts of our code, purely to work around these
issues.

Post by Zach Saw
By the way, I want my money back for all the copies of the BCB6 we've
bought if this is not solved ASAP!

There is a new version of BCB on the way, and I am hopeful that will
fix these bugs among others. This bug is my no. 1 pet peeve, and I
have been chasing hard to flag it for attention for a while now. I
doubt we are going to see any more BCB patches at this late stage, but
with DeXter (codename for next update) scheduled for late this year, I
am hopeful a fix will be available soon. It will probably mean
upgrading, but personally I would take that upgrade if just this bug
was fixed and no others!!!

Did I mention this was my no. 1 pet peeve? <g>

[oh, and I DO expect more than just this issue to be fixed in DeXter in
case you were wondering!!]

AlisdairM(TeamB)

[Zach Saw]

I don't think I have enabled inline functions (in fact, there isn't even a
destructor).
I've lived with other bugs for years now, but this one is really one that we
can't get around. Is there a temporary work around of some sort? This is sad
as our company just bought 4 more copies of BCB6 last week due to expansion.
We are seriously thinking of returning it.

"Alisdair Meredith [TeamB]"

Post by Alisdair Meredith [TeamB]

Post by Zach Saw
*** PUZZLED *** !!!!!
What is going on inside AnsiString? Who is the culprit?
Please help.

This is a very puzzling bug and drove me nuts for years trying to pin
it down. I have done quite a lot of research on BCB destructor bugs
over the years, and there are a few reports in Quality Central that
might help.
The basic advice is 'disable inline functions'. Most of the leak bugs
come from bad code generating expanding constructors/destructor inline.
Without this optimisation I think you will get correct code.
The second advice is 'be alert'. There are still problems when base
classes and data member constructors throw exceptions, and these can
lead to even nastier code generation bugs. I have resorted to 2-phase
construction in several parts of our code, purely to work around these
issues.

Post by Zach Saw
By the way, I want my money back for all the copies of the BCB6 we've
bought if this is not solved ASAP!

There is a new version of BCB on the way, and I am hopeful that will
fix these bugs among others. This bug is my no. 1 pet peeve, and I
have been chasing hard to flag it for attention for a while now. I
doubt we are going to see any more BCB patches at this late stage, but
with DeXter (codename for next update) scheduled for late this year, I
am hopeful a fix will be available soon. It will probably mean
upgrading, but personally I would take that upgrade if just this bug
was fixed and no others!!!
Did I mention this was my no. 1 pet peeve? <g>
[oh, and I DO expect more than just this issue to be fixed in DeXter in
case you were wondering!!]
AlisdairM(TeamB)

[Andrue Cope [TeamB]]

Post by Zach Saw
I've lived with other bugs for years now, but this one is really one
that we can't get around. Is there a temporary work around of some
sort?

I can't immediately see one for the object.

Using a smart pointer for all data members solves the worst of the
problem in the example but may not be practical in a real project. It's
also not necessarily something you can trust given that the code is not
cleaning up correctly in the first place.

In any case it still leaves 4 bytes being leaked and with enough
objects being leaked this could be a problem. Even if the amount of
memory is small it could still easily lead to heap fragmentation.

Hopefully Alisdair has a better workaround since it sounds like he has
experience of this issue.

[Andrue Cope [TeamB]]

Post by Andrue Cope [TeamB]
Using a smart pointer for all data members solves the worst of the
problem in the example but may not be practical in a real project.
It's also not necessarily something you can trust given that the code
is not cleaning up correctly in the first place.

No. This doesn't work. I thought it did once but apparently not now.

[Andrue Cope [TeamB]]

Post by Andrue Cope [TeamB]

Post by Andrue Cope [TeamB]
Using a smart pointer for all data members solves the worst of the
problem in the example but may not be practical in a real project.
It's also not necessarily something you can trust given that the
code is not cleaning up correctly in the first place.

No. This doesn't work. I thought it did once but apparently not now.

Now it's just getting confusing. It seems to depend on exactly what is
in the class declaration. But this doesn't leak:

class LeakMe
{
boost::scoped_array<char> leaked;
public:
__fastcall LeakMe(const AnsiString &str)
{
leaked.reset( new char[ 1024 ] );
throw Exception("LEAKED!");
}
};

..nor this

class TTest
{
char test[ 10000 ];
};

class LeakMe
{
std::auto_ptr<TTest> leaked;
public:
__fastcall LeakMe(const AnsiString &str)
{
leaked.reset( new TTest() );
throw Exception("LEAKED!");
}
};

..Other than of course the object itself as already confirmed.

[Alisdair Meredith [TeamB]]

Post by Zach Saw
I don't think I have enabled inline functions (in fact, there isn't
even a destructor).

All I can suggest is that you check your project options - the majority
of these leaks (in practice) are due to that bug.


If that doesn't solve the problem, you need to start thinking how to
redesign your code around the problem. This is the only way to solve
the other category of bugs - double destruction, and destructors being
called for incomplete objects.

Generally I fall back on 2-phase construction. Implement a constructor
that is guaranteed not to throw, and then call the potentially-throwing
member function to complete contruction. This is best hidden behind a
factory function, so that you can hide 2-phase construction from the
rest of your system.

Yes, it is painful and should be un-necessary. In practice I seldom
need to go this far as disabling inlining solves most my problems, but
it is important to know the trick when needed.


Note you can make the second-phase function private, and your factory
function a friend or your class, or a static member if you prefer.

AlisdairM(TeamB)

[Gillmer J. Derge [TeamB]]

Post by Alisdair Meredith [TeamB]
Yes, it is painful and should be un-necessary. In practice I seldom
need to go this far as disabling inlining solves most my problems, but
it is important to know the trick when needed.

Is disabling inlining something that can be done on a limited basis with
a pragma, or do you need to disable them for the entire project? I
would hate to think you'd be unable to use any inline functions in your
application just because one constructor is causing a problem.

[Alisdair Meredith [TeamB]]

Post by Gillmer J. Derge [TeamB]
Is disabling inlining something that can be done on a limited basis
with a pragma, or do you need to disable them for the entire project?
I would hate to think you'd be unable to use any inline functions in
your application just because one constructor is causing a problem.

Principle of least astonishment.
If you disable inlining everywhere, then you get consistent behaviour
and are rarely surprised.

If you selectively disable inlining when you detect a bug, your code
remains broken until you find the next bug and fix it. Working code
can end up breaking for the oddest reasons during maintenance.


The speed gains we saw in real-world examples from our code simply did
not justify the risk of enabling the feature - so we universally
disable it.

In specific benchmarks, such as using algorithms with vector< string >,
we have seen a factor of 30 or so when measuring speed. Howevever, our
GUI seems just as responsive, so we live with the trade-off.

It also makes project management much simpler - all projects are always
on full debug settings, even the final product.

Of course, we are generating in-house software. This might be a luxury
not afforded to others.

[we have been working with this policy for 3 or 4 years now, no real
user complaints]


AlisdairM(TeamB)

[Chris Uzdavinis (TeamB)]

Post by Gillmer J. Derge [TeamB]

Post by Alisdair Meredith [TeamB]
Yes, it is painful and should be un-necessary. In practice I seldom
need to go this far as disabling inlining solves most my problems, but
it is important to know the trick when needed.

Is disabling inlining something that can be done on a limited basis
with a pragma, or do you need to disable them for the entire project?
I would hate to think you'd be unable to use any inline functions in
your application just because one constructor is causing a problem.

Probably. But it depends on how the source code is handled. The ACE
library, for example, has its own mechanism to disable inlining. The
definitions of the inline functions are in their own file, using a
.inl extension. If ACE's inlining is enabled, then the header
#includes the .inl file and the ACE_INLINE macro expands to "inline".
If ACE's inlining is disabled, then the .cpp file includes the .inl
file, and ACE_INLINE expands to nothing. So the compiler sees
bona-fide inline or non-inline functions depending on build options.

While this is not commonly done everywhere, it is something that
exists outside of ACE. The upside is that you can control it with
fine granularity, but the downside is that one unit may expect a
function to be non-inline, but where it would be defined expects it to
be inlined (and thus does not create the function.) The result is an
undefined external reference at link time. A rebuild is in order.

[Alisdair Meredith [TeamB]]

Post by Alisdair Meredith [TeamB]
This is a very puzzling bug and drove me nuts for years trying to pin
it down. I have done quite a lot of research on BCB destructor bugs
over the years, and there are a few reports in Quality Central that
might help.

OK, trying to find my reports again...

http://qc.borland.com/wc/qcmain.aspx?d=2629

That is the nastiest one, that covers how the code gen changes
depending on whether or not an integer variable is declared before the
object that will fail to construct. Example is a little hard to read
online, but paste it into a code editor and it should help.


I can't find the report that mentions destructors not being called with
function inlining enabled, but at least that one has an implementable
workaround.

Again, I am hoping all the object lifetime bugs to be fixed in DeXter,
and hope the wait will not be too much longer. After all, year end is
less than 4 months away now (and after 3.5 years with BCB6, 4 months
actually begins to sound quite close ;?)

AlisdairM(TeamB)

[Zach Saw]

I'm not sure our company has the resources to upgrade to Dexter when it does make it to the shelf. There are way too many things that we are using which also needs to be upgraded. It would be costing us too much money.

Whether the new version comes out or not, we've just purchased 4 new copies (3 of which is still wrapped in plastic). I'm sure we will feel violated if Borland does not solve the issue for this build, since to the consumers, this product is 1 week old.

I know TeamB is a voluntary group, so I personally am very much grateful for the work you guys are doing. I'm just wondering if you guys know any channels we can file our complaint and get an official response from Borland, since we are Borland's customer.

Thanks in advance.

Post by Alisdair Meredith [TeamB]

Post by Alisdair Meredith [TeamB]
This is a very puzzling bug and drove me nuts for years trying to pin
it down. I have done quite a lot of research on BCB destructor bugs
over the years, and there are a few reports in Quality Central that
might help.

OK, trying to find my reports again...
http://qc.borland.com/wc/qcmain.aspx?d=2629
That is the nastiest one, that covers how the code gen changes
depending on whether or not an integer variable is declared before the
object that will fail to construct. Example is a little hard to read
online, but paste it into a code editor and it should help.
I can't find the report that mentions destructors not being called with
function inlining enabled, but at least that one has an implementable
workaround.
Again, I am hoping all the object lifetime bugs to be fixed in DeXter,
and hope the wait will not be too much longer. After all, year end is
less than 4 months away now (and after 3.5 years with BCB6, 4 months
actually begins to sound quite close ;?)
AlisdairM(TeamB)

[Alisdair Meredith [TeamB]]

Post by Zach Saw
I'm not sure our company has the resources to upgrade to Dexter when
it does make it to the shelf. There are way too many things that we
are using which also needs to be upgraded. It would be costing us too
much money.

I feel your pain.
We have ruthlessly stuck to a policy of no 3rd party components without
source, and use them only where strategically important. A couple of
well-chosen GUI components make the world of difference to a product,
sprinkling with 'neat' utilities pads out the feature count and looks
good at first, but we found too many dependencies beyond our control
hit exactly your problem.

We also make sure we can build and integrate the 3rd party source into
our source tree before proceeding. This means we can upgrade to DeXter
when we choose, rather than waiting for 3rd party support, although we
end up doing the 3rd part ports in the process. Hence, stay with a few
well-chosen libraries that make the porting, if not painless, at least
affordable. For a fresh compiler, it will be well worth the effort!

Post by Zach Saw
Whether the new version comes out or not, we've just purchased 4 new
copies (3 of which is still wrapped in plastic). I'm sure we will
feel violated if Borland does not solve the issue for this build,
since to the consumers, this product is 1 week old.

Did you buy those products with 'Software assurance'? If not, I
suggest you get in touch with your sales rep now to see if you can get
on the scheme. Normally it is only available when you purchase the
product.

It should cost 25% of the price of your original purchase, but entitles
you to a certain number of technical support incidents (such as might
be useful right now!) and more imporantly in this case, entitles you to
automatic product upgrades for the next 12 months. So if DeXter ships
within the next 12 months, you get it for free, no extra charge. That
won't solve your 3rd party costs, but should at least give you the
flexibility to make the move if it turns out to be appropriate.

You can also renew SA for that 25% cost every year, which on Delphi
product cycles should be quite competitive with product upgrades, with
the additional benefit of stronger support. You can also evaluate what
it means to your business in 12 months time, rather than now ;?)

Post by Zach Saw
I know TeamB is a voluntary group, so I personally am very much
grateful for the work you guys are doing. I'm just wondering if you
guys know any channels we can file our complaint and get an official
response from Borland, since we are Borland's customer.

If you have a support contract (or software assurance!), that is the
most direct route.
Failing that, Quality Central is the public bug reporting system:
http://qc.borland.com


Speaking honestly, I am not sure what you will get out of a support
incident other than advice to upgrade when DeXter ships. But you never
know until you try.

Good luck!

AlisdairM(TeamB)

[Leo Siefert]

Post by Zach Saw
I'm sure we will feel violated if Borland does
not solve the issue for this build,

Speaking realistically based on what I have seen in the past, I would
be _very_ surprised to see Borland issue another patch to BCB6 this
late in its life - especially since they have announced that the next
version of BCB will be integrated into the Delphi IDE, a feat which is
sure to take up nearly all of their C++ resources until that product
is released. I don't think I've ever seen them release a patch to a
product after its successor was released.

On the other hand, they have at times offered free upgrades to the
next version of a product when the previous version was bought shortly
before the new product is released. Even if they do not do this, you
might be able to use your problem with the bug to convince them to
offer you a break on the upgrade.

Best suggestion, though, for the long term good of your business,
would probably be to get Software Assurance - even just for the fact
that it might make you look more important to Borland.

- Leo

[Alisdair Meredith [TeamB]]

Post by Leo Siefert
I don't think I've ever seen them release a patch to a
product after its successor was released.

I think this happened with one of the more 'recent' Delphi versions,
but it is certainly the exception that makes the rule.

AlisdairM(TeamB)

[Hendrik Schober]

Post by Zach Saw
I'm just wondering if
you guys know any channels we can file our complaint and get an official response from Borland, since we are Borland's customer.

Wrong vendor.

Post by Zach Saw
Thanks in advance.
[...]

Schobi

[David Dean]

In article <***@newsgroups.borland.com>,
"Alisdair Meredith [TeamB]"

Post by Alisdair Meredith [TeamB]
OK, trying to find my reports again...
http://qc.borland.com/wc/qcmain.aspx?d=2629

Wow, I'm surprised that this one hasn't been opened yet.

[Zach Saw]

I've filed a report in QC.

http://qc.borland.com/wc/qcmain.aspx?d=15800

And some updates after hours of testing.

if you use any of the RTL_DELPHIRETURN classes (Currency, AnsiString, WideString, Variant, TDateTime, Set etc.), do not let the compiler type cast for the parameter of a constructor - it will end up generating wrong code and in some cases, you will even get access violation.

This is a critical bug of C++ Builder. Unfortunately, I don't think anyone at Borland is paying attention to C++ Builder 6 any more.

I'm seriously considering a switch to Microsoft VC++ for our company, since it will already take a huge effort to rewrite our code to make it "compatible" with Borland's C++ "standards". Even then, we may end up with yet another bug. If this is Borland's 3 1/2 year-old "matured" product, I don't think jumping onto the Dexter wagon when it is released is wise. We will certainly be returning the 4 new copies of C++ Builder we've just purchased, if only Borland is even willing to entertain their clients. In fact, after reading all the issues and managed to reproduce tonnes of them from Borland's QC, and the fact that some issues have been there since 2 years ago really bothers me. Borland obviously doesn't care if their C++ community sticks with them. Borland suck big time when it comes support. I worked in Intel prior to my current job -- if there is even a remote bug in the CPU, we would have fixed it already. Otherwise, there would have been a recall (there are a lot of recalls unknown to the public, only to the system integrators like Dell / HP etc.).

If you are not convinced you should ditch Borland the soonest you can, just take a look for yourself over at QC. The oldest open issue is dated 3/5/2002. That's almost the entire lifetime of BCB6. I'm not sure how I will ever trust Borland to deliver a working product in the future.

Anyway, a sincere thanks to all the folks who replied.

[Hendrik Schober]

Post by Zach Saw
[...]
If you are not convinced you should ditch Borland the soonest you
can, just take a look for yourself over at QC. The oldest open
issue is dated 3/5/2002. That's almost the entire lifetime of BCB6.
I'm not sure how I will ever trust Borland to deliver a
working product in the future.
[...]

Well, this is software. It's not really uncommon
to have open bugs sitting there for years. /If/
they affect only a few customers...

But the problem with Borland is the support. In
fact, there's almost none. A few patches once in
a while -- with not even as much as a list of what
bugs they actually fix! --, a few non-commital
appearances of JohnK and AndersO here, and then
it's only TeamB, which is empowered only by their
commitment and (I guess) access to all the products.
That's not much. It's almost nothing. (Which does
not belittle the heroic efforts of the TeamB folks!)

I have found bugs in other compilers (Microsoft,
Metrowerks, Comeau, GCC) and none of them is the
black hole that Borland has been for years. I had
been an enthusiastic Borland user once. Working
with their product everyday, I have certainly
found a number of bugs -- and never ever had a
single feedback on one of my bug reports. I have a
bug that I found with BC5 (not BCB, mind you), which
I had reported back then. I don't think it was a
geeky one (not templates, no exceptions) and I had
a small repro case. Meanwhile there's been two or
three bug reporting schemes at Borland and the bug
is /still pestering their latest compiler version/.
Isn't that amazing?
For every other bug I ever encountered in any other
compiler I always (A) got free support for the
incident and (B) either a workaround or a patch.
Within /days/. Probably even more importantly, I
have always had some individual on the other end
communicating with me until the problem was solved
for us. I was regularly updated on the (internal)
state of the issue, asked for more information,
passed on internal information as to what triggers
this -- all in order to allow both sides to solve
the issue in cooperation. And yes, this applies to
commercial applications, too, and it applies to
such small vendors as Greg Comeau's company the
same way as to the giant Microsoft. (Although the
by far most outstanding individual that I ever
encountered in any support department was the
legendary MWRon of Metrowerks, may he rest in
piece.)

Schobi

[Zach Saw]

Thanks for the answer. I was starting to wonder if I'm the only one fed up
with Borland. The only pain now is the time and resource we need to convert
all our code to non-borland dependent. That's a huge feat on its own.

Post by Hendrik Schober

Post by Zach Saw
[...]
If you are not convinced you should ditch Borland the soonest you
can, just take a look for yourself over at QC. The oldest open
issue is dated 3/5/2002. That's almost the entire lifetime of BCB6.
I'm not sure how I will ever trust Borland to deliver a
working product in the future.
[...]

Well, this is software. It's not really uncommon
to have open bugs sitting there for years. /If/
they affect only a few customers...
But the problem with Borland is the support. In
fact, there's almost none. A few patches once in
a while -- with not even as much as a list of what
bugs they actually fix! --, a few non-commital
appearances of JohnK and AndersO here, and then
it's only TeamB, which is empowered only by their
commitment and (I guess) access to all the products.
That's not much. It's almost nothing. (Which does
not belittle the heroic efforts of the TeamB folks!)
I have found bugs in other compilers (Microsoft,
Metrowerks, Comeau, GCC) and none of them is the
black hole that Borland has been for years. I had
been an enthusiastic Borland user once. Working
with their product everyday, I have certainly
found a number of bugs -- and never ever had a
single feedback on one of my bug reports. I have a
bug that I found with BC5 (not BCB, mind you), which
I had reported back then. I don't think it was a
geeky one (not templates, no exceptions) and I had
a small repro case. Meanwhile there's been two or
three bug reporting schemes at Borland and the bug
is /still pestering their latest compiler version/.
Isn't that amazing?
For every other bug I ever encountered in any other
compiler I always (A) got free support for the
incident and (B) either a workaround or a patch.
Within /days/. Probably even more importantly, I
have always had some individual on the other end
communicating with me until the problem was solved
for us. I was regularly updated on the (internal)
state of the issue, asked for more information,
passed on internal information as to what triggers
this -- all in order to allow both sides to solve
the issue in cooperation. And yes, this applies to
commercial applications, too, and it applies to
such small vendors as Greg Comeau's company the
same way as to the giant Microsoft. (Although the
by far most outstanding individual that I ever
encountered in any support department was the
legendary MWRon of Metrowerks, may he rest in
piece.)
Schobi
--
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett

[Andrue Cope [TeamB]]

The only pain now is the time and resource we need to convert all our
code to non-borland dependent. That's a huge feat on its own.

You *might* want to wait a few months. Although there is no confirmed
release date yet for BCB's replacement it seems likely it will either
be at the end of this year or beginning of the next.

[Duane Hebert]

Post by Andrue Cope [TeamB]
You *might* want to wait a few months. Although there is no confirmed
release date yet for BCB's replacement it seems likely it will either
be at the end of this year or beginning of the next.

This would probably be more viable if there was some information
as to what you would be waiting for.

[Andrue Cope [TeamB]]

Post by Duane Hebert
This would probably be more viable if there was some information
as to what you would be waiting for.

There has been /some/ information but I agree that there's probably not
been enough to keep everyone happy.

[Duane Hebert]

Post by Andrue Cope [TeamB]
There has been /some/ information but I agree that there's probably not
been enough to keep everyone happy.

From what I've seen, there has been some info wrt the new IDE
and some mention of using dinkumware. Probably both good things,
though I didn't see much in the way of project management stuff
in the IDE. But I've seen nothing about any bug fixes etc. At this
point, it is still possible that it will be the same stuff with a new IDE
and a different STL library. One could assume that the move to
dinkumware would indicate a more compliant compiler but one could
be wrong :-)

[Andrue Cope [TeamB]]

Post by Duane Hebert
But I've seen nothing about any bug fixes etc.

http://bdn.borland.com/article/0,1410,32958,00.html

Specifically (I've edited it for the newsgroup):

Q.will there be a new c++ compiler / linker? Will it be 100% Ansi C
compliant? All boost libraries to compile? Even Spirit and crypto++?

A.We've done some work on conformance for Boost and for ACE. We're
going to specifically target boost and some customer complaints. We
won't be 100% ANSI compliant

and

Q.what about the compiler generating faster code?"
A.The focus on this release is more language conformance and IDE
features rather than code generation

I will prod TPTB for more information again as that's always a
worthwhile task :)

[Duane Hebert]

Post by Andrue Cope [TeamB]
Q.will there be a new c++ compiler / linker? Will it be 100% Ansi C
compliant? All boost libraries to compile? Even Spirit and crypto++?
A.We've done some work on conformance for Boost and for ACE. We're
going to specifically target boost and some customer complaints. We
won't be 100% ANSI compliant

This sounds good but I would like to have some input as to
what percentage of bugs on QC will be addressed and
eventually a list of those fixed when the product ships.

That's pretty much standard procedure with most vendors
but I don't think I've ever seen Borland do this when rolling
out upgrades.

[Andrue Cope [TeamB]]

Post by Duane Hebert
This sounds good but I would like to have some input as to
what percentage of bugs on QC will be addressed and
eventually a list of those fixed when the product ships.

Well you could check through QC and see which bugs have been passed
through to the internal database. That would give you some idea of what
they are working on.

But generally I'm not sure what you're after. It's obvious that the IDE
is 'one big bug fix' and Borland have stated that the compiler is being
bug fixed. I assume you're not looking for a daily progress report :)

I agree that a list of bug fixes and improvements to the compiler would
be nice when the product finally ships (or at least some kind of
compliance statement) but tbh it'll be a such a big leap that I don't
think it'll add anything. BCB6 is over two years old, the new product
will be..a new product. There will implicitly be a lot of changes and
improvements to it. Quantifying that in a list would probably mean a
list that is several pages long and most people won't bother to read it.

Borland are not just hooking BCB6 into Delphi, shoring up the rough
edges and calling it a good 'un. They are expending considerable effort
in adding BCB6-like functionality to Delphi. Yes, it's based around the
existing compiler but that compiler is being modernised and bug fixed.

[Duane Hebert]

Post by Andrue Cope [TeamB]
Borland are not just hooking BCB6 into Delphi, shoring up the rough
edges and calling it a good 'un. They are expending considerable effort
in adding BCB6-like functionality to Delphi. Yes, it's based around the
existing compiler but that compiler is being modernised and bug fixed.

What I would like to see is a list of bugs/problems that
have been addressed with each new release. Whether
or not Borland considers Dexter to be an upgrade to
BCB or not, most of us do. Why would I consider
buying it if it has the same bugs that the current
compiler has? Granted, a new IDE will be a major
bug fix but there are myriad bugs listed in QC that
have been there since BCB4 or before.

FWIW, Borland is the only supplier that we deal with
that doesn't do this. It's always been a question of
trying the new version to see if it's better. At this point,
the only way my company is going to purchase anything
from Borland will be if we know that it fixes some problems
that we have and then it will likely only be a copy or two
to use for our legacy support.

[Hendrik Schober]

Post by Andrue Cope [TeamB]
[...]
Borland are not just hooking BCB6 into Delphi, shoring up the rough
edges and calling it a good 'un. They are expending considerable effort
in adding BCB6-like functionality to Delphi. Yes, it's based around the
existing compiler but that compiler is being modernised and bug fixed.

And users are supposed to rummage through QC to
find out what is fixed? (Not to mention the vague
"modernization" term...) Sorry, but I find this
quite pathetic.

Schobi

[Andrue Cope [TeamB]]

Post by Hendrik Schober
And users are supposed to rummage through QC to
find out what is fixed?

For now, yes. It hasn't been released yet. Development is still in
progress. We don't know yet what Borland will issue in the way of bug
fix lists or compliance statements.

[Duane Hebert]

Post by Andrue Cope [TeamB]

Post by Hendrik Schober
And users are supposed to rummage through QC to
find out what is fixed?

For now, yes. It hasn't been released yet. Development is still in
progress. We don't know yet what Borland will issue in the way of bug
fix lists or compliance statements.

No we don't. Which is why I mentioned it here. Borland doesn't
usually do this. They should start.

[Andrue Cope [TeamB]]

Post by Duane Hebert

Post by Andrue Cope [TeamB]
For now, yes. It hasn't been released yet. Development is still in
progress. We don't know yet what Borland will issue in the way of
bug fix lists or compliance statements.

No we don't. Which is why I mentioned it here. Borland doesn't
usually do this. They should start.

Agreed. Your concerns will be passed on :)

[Duane Hebert]

Post by Andrue Cope [TeamB]
Agreed. Your concerns will be passed on :)

Thanks. Couldn't hoit.

[Hendrik Schober]

[Please trim your quotes. There's no need to
quote 3k of text just to add three lines.]

Post by Zach Saw
Thanks for the answer. I was starting to wonder if I'm the only one fed up
with Borland. The only pain now is the time and resource we need to convert
all our code to non-borland dependent. That's a huge feat on its own.

Depending on your needs you might be able to
wait a few months just to see whether the next
compiler fixes the problem. I know that this
doesn't solve the fundamental problem with
Borland, but it might get your bug fixed w/o
you spending several man months.
OTOH, if your UI is well separated from your
application logic, you might want to put a C
API between them. Then you can port your app
logic to whatever compiler you want and
dynamically link it to the VCL GUI. (If you
have a VCL GUI.)

Post by Zach Saw
[...]

Schobi

[Duane Hebert]

Post by Zach Saw
Thanks for the answer. I was starting to wonder if I'm the only one fed up
with Borland.

No.

Post by Zach Saw
The only pain now is the time and resource we need to convert
all our code to non-borland dependent. That's a huge feat on its own.

You may find that after the initial time investment that you actually save
production time. I would certainly suggest separating the GUI stuff
and only using VCL with the GUI stuff. Regardless of whose tools
you use, this makes sense. Also, if you ever want to do portable code,
you'll find that the gui stuff is the bit more likely to be platform
dependant.

[Leo Siefert]

Post by Zach Saw
Compile and run this without the IDE (i.e. run the exe file).
You'll have Windows complaining low virtual memory in seconds (open task
manager and watch out for the virtual memory used column).

Ok, late response here, but I finally took the time to try this out -
especially since some of my own apps use classes with const
AnsiString& constructors to which I pass const char*.

Followed instructions, but when I run the app I do not see a problem -
it ties up the CPU of course, and task manager shows a large block of
page file memory allocated as soon as I hit the button, but the loop
runs to completion with no further memory allocation and no negative
impact on my system. Have run it a number of times with different
compile options, etc. but with no ill effects. In fact, I ran a
practical test of maxed-out memory by reloading a monster app that
takes _much_ less time to load the second time due to memory caching
and it loaded quickly after running this app many times.

So I gotta ask: "Where's the beef?" Is there something important that
I'm missing here that could make the difference?

Is it possible that you do not have all of the available patches
applied to BCB6? If so, patch and try again. Be sure that you do not
miss the recent linker patch - it is not included in the regular BCB6
numbered patches.

- Leo

[Zach Saw]

Try enabling codeguard. Or use an alternate memory manager - one which will
detect memory leaks. If you modify your code a bit -- I've tried adding a
line such as "if (!new LeakMe("test")) Button1->Enabled = false;", and guess
what, Button1 is disabled after the loop, indicating a completely wrong code
generation by the BCB Compiler. Button1->Enabled = false is after the
exception, it should not be carried out. So imagine if such a simple thing
would go wrong, what else can go wrong? Anyway, I would advice you to stop
using Borland products for critical apps.

Post by Leo Siefert

Post by Zach Saw
Compile and run this without the IDE (i.e. run the exe file).
You'll have Windows complaining low virtual memory in seconds (open task
manager and watch out for the virtual memory used column).

Ok, late response here, but I finally took the time to try this out -
especially since some of my own apps use classes with const
AnsiString& constructors to which I pass const char*.
Followed instructions, but when I run the app I do not see a problem -
it ties up the CPU of course, and task manager shows a large block of
page file memory allocated as soon as I hit the button, but the loop
runs to completion with no further memory allocation and no negative
impact on my system. Have run it a number of times with different
compile options, etc. but with no ill effects. In fact, I ran a
practical test of maxed-out memory by reloading a monster app that
takes _much_ less time to load the second time due to memory caching
and it loaded quickly after running this app many times.
So I gotta ask: "Where's the beef?" Is there something important that
I'm missing here that could make the difference?
Is it possible that you do not have all of the available patches
applied to BCB6? If so, patch and try again. Be sure that you do not
miss the recent linker patch - it is not included in the regular BCB6
numbered patches.
- Leo

[Darko Miletic]

Post by Zach Saw
Folks,
This is a show stopper!!!

Borland compiler has quite a few problems with exceptions inside
constructors. Here are some of reported qc issues:

"Destructor is called if an object allocated from the heap throws in
constructor."
http://qc.borland.com/wc/qcmain.aspx?d=5122

"Incorrect Stack Unwinding From Member Functions"
http://qc.borland.com/wc/qcmain.aspx?d=1914

"Double destruct/destruction of partially constructed object when
contructor throws exception"
http://qc.borland.com/wc/qcmain.aspx?d=2629

In general avoid passing temporaries, just pass already created object
by reference.

Darko