Board index » cppbuilder » Re: SHOW STOPPING memory leak bug in C++ Builder

2005-09-09 09:06:39 PM
cppbuilder57
Leo Siefert wrote:
but it is certainly the exception that makes the rule.
AlisdairM(TeamB)
 

"Zach Saw" < XXXX@XXXXX.COM >wrote:
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
 

No effects whatsoever. Confirmed.
"Ed Mulroy" < XXXX@XXXXX.COM >wrote in message

{smallsort}

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.
"Leo Siefert" < XXXX@XXXXX.COM >wrote in message

Zach Saw < XXXX@XXXXX.COM >wrote:
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
 

Zach Saw < XXXX@XXXXX.COM >wrote:
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
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
 

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.
"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message

Zach Saw wrote:
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.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

[Please trim your quotes. There's no need to
quote 3k of text just to add three lines.]
Zach Saw < XXXX@XXXXX.COM >wrote:
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.)
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
 

"Zach Saw" < XXXX@XXXXX.COM >wrote in message
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.
 

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote in message
as to what you would be waiting for.
 

Duane Hebert wrote:
been enough to keep everyone happy.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

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 :-)
 

Duane Hebert wrote:
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 :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote in message
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.